Part II: What’s Next with Continuous Integration & Continuous Delivery

More and more teams are advancing from Continuous Integration into some flavor of Continuous Delivery, and the rise of provisioning and deploy tools makes it easier than ever to get started. I sat down with Sarah Goff-Dupont, Product Marketing Manager for Atlassian, maker of Bamboo, recently to talk about this and get the very latest on Continuous Integration, Continuous Delivery and where it is all headed. The following is the second in a 2-part series. Missed Part One? Read it now.

What challenges to the adoption of CD do you see out there now? How do these challenges differ for smaller and larger enterprises?
One of the big challenges is getting your environments fully standardized so that a deploy to QA goes through exactly the same steps as a deploy to production.  Provisioning tools and the "configuration-as-code" movement are helping teams overcome this, however.  The other big one is application architecture.  A product that was born 10 years ago just might not be designed in a way that lends itself to automated deploys, or it's evolution may have made it so complex that deploying it is something of an art form.

The older and bigger the company, the gnarlier these challenges tend to be.  With the constant pressure to pump out new functionality, it's hard to fight for the time needed to refactor the application or standardize all the environments.  But teams who have made that investment will tell you that it does pay off.  You just have to trust in the "go slow in order to go fast" axiom.

What are the boundaries of CI, or are there none?
We've yet to find a way to continuously integrate my household chores.  Is it too much to ask for an automated system that gathers up the dirty clothes, washes them, folds them, and puts them away?? Seriously though, I think exploratory testing is a boundary that CI isn't able to cross just yet.  We still need humans to poke around our applications in ways that their designers and developers would never have anticipated.  If you haven't anticipated the use case, you haven't written an automated test for it; therefore it's not part of your CI.

You can bridge this gap somewhat by adding a "needs automation" flag to your issue tracker so bugs found by exploratory testing can be tracked for inclusion in your test suite.  It's an easy way of making a to-do list for your automation engineers.  But the gap remains, nonetheless.  For now.  I guess we can add that to my longer-term vision for CI: a robot that performs user actions in random combinations to uncover those crazy edge-cases.

Do you think large enterprises will ever be able to achieve end-to-end automation from development through to production, or will certain manual actions remain?
I'm pretty sure we could find a few large enterprises that already do, if we looked hard enough.  The ability to achieve end-to-end automation is limited primarily by your degree of confidence in your own tests, processes and tools.   I see no reason why a large application can't be fully automated if it is well-designed, ruthlessly tested (ruthlessly!), and deployed and monitored by systems that are themselves the subject of ruthless testing.  A lot of people might dismiss that attitude as naive, but there are big companies out there taking steps to make that a reality.  For example, Netflix built this thing called the Chaos Monkey that randomly takes down servers in their pre-production environments, causes network interruptions that make deploys fail, etc.  If their systems can handle the Chaos Monkey's abuses in an automated way, they know those systems are in good shape.  That's done a lot to help them achieve extraordinary uptime for such an enormous and heavily-trafficked product.

With regard to automated deploys all the way through production, organizations of all sizes have to consider whether that's something they even want.  Is it too disruptive to my users if I give them new functionality several times a day?  Do we want to strategically time a release so marketing can make a big splash around it?  There are perfectly legitimate reasons for wanting to send new builds to production less frequently than you send them to QA.  Bamboo supports this workflow by letting users designate any step in their pipeline as push-button.  So you might do continuous integration and delivery of all your builds up to your staging environment, but pause there.  Then when you're ready to go live, you select the build you want to deploy and just push the button to resume your pipeline.  You can set up that sort of thing in most other CI servers as well, though it may not be quite as elegant.

How do you visualize the relationship between Change and Release Management and continuous delivery? Can fully-automated deployment pipelines be implemented in a controlled environment?
In many ways, automated deployment actually aids change and release management because of the audit trails it leaves behind.  You can see which code changes are included in a build, and which user stories or issues they relate to.  You can mark a version in your issue tracker as "released" and kick off a production deploy in a single orchestrated action.  You can see whether a certain deploy was triggered automatically or by a person, and exactly when it started and completed.   You can also schedule deploys from separate systems to start at specific times so everything happens in concert.

Workflows that require a human sign-off for each deploy can be accommodated by the pause-and-push-button process I just described.  And most CI servers can link tickets from your issue tracker to builds, which means the approvals can be done that way instead of with emails, and it all stays neatly tied together.  Again, the tools to fully automate a pipeline already exist (and are getting better all the time).  It's your own processes, tests and confidence in them that are more of an x-factor.   And that's great news because those things are 100% under the control of each organization.

Special thanks to Sarah for this great contribution. We hope to see you here in the future!
_______________________________________________________________

As Product Marketing Manager for Atlassian Bamboo, Sarah has been working in software for over 10 years as a manual tester, automated test engineer, scrum master and now as a marketer for Atlassian Bamboo. As a champion of Agile development and automation, she loves talking to developers about their triumphs and their frustrations, then blending those insights with her own experience and sharing it. It's all about making life easier for the nerds.