|
|
![]() Deployment Automation: The End of Plug-n-PraySpeaking to a customer recently, I was told: "Honestly, our favorite thing about moving to AnthillPro is that we've moved beyond 'Plug-n-Pray' deployments. You know, many of our deployments were so scary we'd have a bunch of people in the office or on a call all weekend to execute and debug the deployment and then have all hands on deck Monday morning to deal with the inevitable problems. We were all so stressed and tired that we were pretty much useless for a few days after the deployment. It always feels great to hear that your product isn't just good for productivity, traceability, etc but that you're also making people's lives better by giving them their weekends back. But I think it's important to call out that changes in process for this customer and others like them that are equally important.
It comes down to making sure your process can be automated. Automating that process. And not circumventing the automation - even in test environments. Each of those three elements delivers some unique gains. AnthillPro is a Maven Repository!and it's friendlier with the Maven repo you already have
AnthillPro's integrated build artifact repository is one of our favorite things about the tool. After all, if you're going to support moving a build through it's lifecycle towards production with deployments and tests, it's helpful to manage the files that are "the build".
The repository is also hugely helpful for managing build time dependencies between projects. However, teams using Maven don't necessarily need a new repository and definitely don't want a new way of specifying dependencies. Read on for how... Build and Deployment Pipelines
Michael Sayko, a software configuration management consultant based in Austin, Texas, wrote a great article for CM Crossroads on the advantages of a build pipeline approach to build and deployment automation. You should check it out.
I'm a big fan of the pipeline metaphor, along with related concepts like continuous delivery and DevOps, it encourages the team to think about automation from build to production release. That said, it's important to note that the pipeline is really an idealized view of the world. Some builds will not go through their lifecycle by following the standard release pipeline. An emergency will require a rush that skips some testing environments or sign-offs, or after going to UAT, the build is re-deployed to QA to check something, or..., or..., or... - the real world collides with the plan. A build pipeline is a good model for planning your automation, but make sure your implemented automation is ready to handle the real world along with the ideal case.Q&A from Enterprise Build-Deploy-Test-Release Webinar
Last week Jeffery and presented BDTR Automation in the Enterprise where we discussed the drivers for expanding automation from the team level to the enterprise level, as well as the requisite technical and social components to the design and rollout of such a system. We had more questions than we could cover in the Q&A period. Below is a selection of the questions asked. I've taken the liberty of combining some related questions.
Q: If each team (or functional silo) has its own automation, do you suggest that a separate team own the glue processes that span those silos? ... Questions an Enterprise CI System Should Answer
In our webinar on Build-Deploy-Test-Release Automation in the Enterprise (replayable here), we observed that there are a number of questions that cut across teams. These are questions that we suggest than an enterprise system should be able to help with. A couple people asked for the list of questions we presented in the slides. Read on for the full list of questions...
Build Types Vs. Build Promotions
When it comes to builds, we often talk about build types - a development build, an integration build, a release build, etc. We very rarely hear people talking (or writing) about build promotions.
Archiving Some Past PresentationsWith the new website, the presentations below have (at least temporarily) lost their home. So, they are being archived for the time being here. Archiving the EJB Benchmark
We released an EJB benchmark in early 2002 based on some work we did early on with EJBs. With the new site design, the EJB benchmark would have been lost, and that's why it ended up on my blog for archiving.
The Nuts and Bolts of Release Builds
Given that I work for a company that develops an automated build management server, I get to hear about some of the different build and release processes that are in use. Generally, they all follow the same structure, but there are some variations. In this month's column, I would like to present that general structure and talk a little about some of those variations.
Part 2 of Sloppy Deployments
In my previous post, I wrote about the evils of sloppy deployments. Two main practices may lead to what I call "sloppy deployments," they are ...
|