It seems like everyone loves continuous integration. I’ll come out and say it- I love continuous integration! When we talk about the most widely adopted Agile practices, this one comes up the most. Its positive benefits as a feedback mechanism provide a quantum leap forward in how development organizations think about their code. I find it very difficult to see any downside in doing continuous integration, seriously what’s not to love?
Modern day continuous integration servers have 3 functions: Detect if a new build is needed, execute build, and notify people of the results. This is a great way of facilitating feedback to developers and allowing them to adapt and resolve problems.
But there’s something lurking in the shadows that nobody is talking about, maybe because people aren’t even aware that it’s a problem. Maybe it’s because we don’t want to ruin our love affair with CI and we’re all in denial.
What happens when those builds are done? What about the rest of “it”?
When I say “it” what I really mean is:
Most development environments include such things as complex application servers, automatic testing, release processes, compliance, audits, databases, 3rd party libraries, build dependencies, code analysis, unit tests… and another 1,000 other things I don’t have enough space to list here. How can you deal with this? Getting feedback to my dev team is a great targeted way to let people know code is broken, but isn’t this feedback useless if you can’t get the product out the door?
If I take an example build lifecycle of an application which is:
1.) Build Application
2.) Test
3.) Deploy to environments (DB) (APP SERVER) <- by hand
4.) Test
5.) Redeploy (DB) (APP SERVER) (PROD) <-by hand
This may seem like easy in this example, but if we took all of these steps in the real world, this could represent hundreds of servers. And this process will have to be repeated for every version of the product.
The crux of this issue is that if any of these steps are not performed 100% correctly, it translates to real dollar$ lost for the organization. These operations have to perform like clockwork.
Taking Continuous Integration to the Next Level
This is why I believe bringing continuous integration to the next level starts with the concept that the build produced from the CI server is just the beginning. Setting up a simple CI server and producing a build is easy, but managing it through the rest of its life is the real trick.
In a real example of this, we could take
1.) Build
2.) Run automated tests
- If test succeeds: Deploy to to environments (DB) (APP SERVER)
- If test fails: Notify dev team
3.) Manual Testing in QA environment
4.) Approval process
5.) Redeploy (DB) (APP SERVER) (PROD)
Using AgileCycle RM
In this scenario I’m taking a version of the results from a CI build, run automated tests on them, monitor the test output and wait for success or failure. If there is success then deploy all components of the application, this includes a database components and a java war component. The build will then sit in QA for manual testing until its marked approved by the QA team, managers and operations team for deployment to production.
The idea here is if we automate these processes and decisions based on build, automated tests and approval process, you can produce code quickly and at a more rapid pace. If you can produce a clockwork-like automation around your build/test/deploy related processes, your team can spend time on what’s most important: Getting code out the door.
