Feature:

Integrating continuous development into the ALM process: Avoiding common pitfalls

By Jason Tee

TheServerSide.com

More and more organizations are embarking upon an Agile based initiative that makes continuous integration (CI), continuous development and continuous deployment a process that is central to application lifecycle management (ALM). Of course, there are common pitfalls that can be easily avoided if organizations keep focused on some key objectives, and success can be easily measured if teams are looking at the right metrics. Here are some insights on how to keep the process on track when integrating more and more continuous processes into the software development lifecycle (SDLC).

Automate, then automate some more

You have to automate deployment. You can't have a big chunk of manual processes in deployment that are run by hand.

John Smart, author of Jenkins: The Definitive Guide

Automated testing is the foundation of continuous integration and continuous delivery, and you need two layers of testing to make this process work. Solid automated unit tests provide confidence in the code, but that's not enough to give confidence to the testers, QA team, and stakeholders. For these groups, you need communication-focused acceptance tests. The better your communication, the higher the level of confidence—and the smoother the delivery.

The process doesn't end there. John Smart, author of Jenkins: The Definitive Guide, describes the next step, "You have to automate deployment. You can't have a big chunk of manual processes in deployment that are run by hand, or tasks that you have to ask your SysAdmin to do. Automate as much as you possibly can." Yes, there will still be some holdouts. John says organizations are especially reluctant to use automation when it comes to database interactions such as updates and configuration. If possible, find ways to minimize these risks to encourage greater automation.

Tools only work as well as the people using them

Michael Huetterman, author of DevOps for Developers says the right tools are important. "Jenkins is a build and delivery hub. It's a neat example of a Swiss army knife that can assist both development and operations teams." However, he says that even more important than tools is a basic mindset along with Agile approaches and processes. He's seen many times that Jenkins or Hudson is used by the development team but it's more or less an island. Development uses it and integrates the code, but the whole team doesn't exchange and reuse these tools across department borders.

Michael favors a one team approach to connect all stakeholders. Developers, coders, programmers, testers, and operations engineers should all be using the same processes and tools. Of course, that means finding a toolset that everyone will actually use. That's probably a good place to start the communication process. Have team members sit down together to describe how they typically use their tools, new features they would like to have, and what they absolutely must have. Fortunately, Jenkins is an endlessly extensible platform with a huge variety of plugins to help keep everyone happy.

Getting the whole organization on board

Teresa Ann Gracias, a software developer at ThoughtWorks says one of the most common pitfalls she sees is lack of investment by the C-suite. They just don't seem interested in taking responsibility for promoting change. "Continuous delivery is not perceived as a cultural transformation. Executives see it as something a team of developers needs to implement. Executives need to have a stake in putting continuous delivery into practice and understanding the benefit to them from a business perspective." Otherwise, continuous delivery is done on an ad-hoc basis. Continuous delivery and related methodologies like behavior driven development can offer measurable outcomes on a number of fronts. So, it's beneficial to ask the VPs what results they want to see—and find a way to build those into the acceptance criteria.

Metrics matter, so know your numbers

Executives need to have a stake in putting continuous delivery into practice

Teresa Ann Gracias, ThoughtWorks Developler

Speaking of numbers, is transitioning to continuous integration even worth it? Maybe not. Paul Swartout, author of Continuous Delivery and DevOps: A Quickstart Guide, puts it bluntly. "Like any project, there has to be a benefit and it has to be measurable. There's no point in doing something if there's no benefit." He says you have to know your currency—what really matters to your organization. That might be speedier delivery, being able to deploy ten times a day, fewer escape defects, or a reduction in mean time between failures.

Obviously, you need to know the before numbers so you can measure improvement after implementing continuous integration practices. This is particularly helpful for non-functional requirements like throughput since it creates a meaningful dialogue with stakeholders. You can use any number of measures that are industry standard (ITIL, CMMI, etc.) At the same time, don't get so caught up in these figures that you lose sight of the basics. Besides making your team more productive, it should be promoting a healthy work culture.

What tips do you have for organizations adopting Agile and continuous development techniques? Let us know.

05 Feb 2014

Related Content

Related Resources