Speaking 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.

That's all gone now that we've automated. Most of those deployments are a 30 minute effort Friday night, and we don't do anything special on Mondays."

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.

• No more Word documents containing the deployment plan They're hard to follow, and get out of date.
• No fixing application server configuration in Test environments by hand: Instead of fixing a broken configuration of the test environment by hand (which often results in the same breakage in Prod), the teams fix the automation to set to the configuration properly in all environments and redeploy to Test.
• Repeatable Deployments: An automation system can only deploy that which is automateable.  This rules out funky processes that rely on guess work and gut checks. The process of figuring out the deployment process well enough to automate it makes the process better. (see our WebCast on using automation to shine a light on your process.

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'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...

Read more...

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.

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?
...

Read more...

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...

Read more...

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.

Read more...

With the new website, the presentations below have (at least temporarily) lost their home. So, they are being archived for the time being here.

Read more...

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.

Read more...

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.

Read more...

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 ...

Read more...