days
1
1
hours
0
1
minutes
4
2
seconds
3
6
Leveraging automation in a Continuous Delivery model

4 tips for automating your CD pipeline

Kaushal Amin
CD

Macro photo of tooth wheel mechanism image via Shutterstock

Automation is an essential piece of the CD model, providing much-needed consistency and faster turnaround time. Automated processes are easily repeatable as often as you need, and they’re transparent, so you always have a clear audit trail. However, there are problems to overcome in seeking to get the maximum value from automation in a CD model.

Continuous Delivery is quickly becoming the new standard for software development. It enables developers to release software changes faster than before and more often, without sacrificing quality. As many as 65% of software developers, managers, and executives report that their organizations are using Continuous Delivery (CD) according to an Evans Research survey.

Automation is an essential piece of the CD model, providing much-needed consistency and faster turnaround time. Automated processes are easily repeatable as often as you need, and they’re transparent, so you always have a clear audit trail. However, there are problems to overcome in seeking to get the maximum value from automation in a CD model.

First things first

What should you automate? In an ideal world, the answer would be – everything. But, realistically, that’s not possible at the beginning, as you can’t afford to wait for everything to complete. What you can do is start with the low hanging fruit.

Automating your build procedure is the first step towards implementing CD. Every developer should be able to independently check in the code they’re working on and trigger the automated build process. An automated build process eliminates the risk of errors introduced from manual build mistakes and cuts dependency on specific personnel with knowledge of the build procedure. Also, continuous automated execution of frequent builds makes it easier to investigate problems, because you can trace things back to a specific, small code check-in (and not a massive code check-in).

It also cuts down on the time it takes to let developers know of problems caused by checked-in code and thus developers can quickly resolve the issues.

Automating your testing

The next step is to tackle what takes the longest cycle time besides coding.  Obviously, this is testing. It can sometimes feel like testing gets in the way of doing effective CD. The best way to combat that is to automate repetitive test cycles, such as regression test cases, tests that require repetitive testing across multiple data sets, browser compatibility tests, and anything that’s particularly prone to human error.

Test automation is expensive at the outset, so you must carefully assess and prioritize what will deliver the best return on your investment. Keep it small and focused. Test automation can also free your manual testers from mundane tasks. Exploratory testing is quicker, but also more effective.

It’s important to automate unit and integration tests so that you can ensure the basic functionality of your software is working as part of the automated build cycle. More complicated testing, such as the end-to-end UI workflow, can be tested post-build cycles as part of your scheduled deployment to the QA environment. This can also be automated to cut down the time it takes to reach production.

The need for speed

One of the big challenges with complex scenario testing in QA environments is running all your automated test scripts quickly enough, so that regression testing can be completed before the next scheduled deployment. If you’re deploying four to five builds to QA every day, then they can start to pile up due to automated QA regression cycles taking several hours.

There are a couple of possible strategies you can employ to speed things up, but neither is ideal. You could limit the number of builds you produce, scheduling them to run only once a day to ensure that there’s enough time for automated regression tests to complete. This is a step back from CD and it will make problems harder to investigate because each individual build will contain too many code changes from too many developers.

The other option is to assess the changes going into each build and analyze which scripts you need to run. Perhaps you focus on the core functionality and areas where changes have been made and drop some of your other scripts for this cycle.

There are two problems with this – firstly, you’re introducing a manual step, because someone must make an intelligent decision on what scripts to run. Secondly, you’re introducing room for error because changes may impact other areas of code in unforeseen ways. It’s a risky trade-off.

The best plan is to design your automated regression testing so that tests can run in parallel as much as possible. That way you can execute across multiple boxes for optimum scalability.

Further, part of your automated testing procedure could include an automated assessment of code changes that could determine which test cases need to be run for each build. This is a situation that’s crying out for a reliable, intelligent algorithm that can get consistently good results.

Long-term solution

Finally, the long-term solution is to look at the architecture of your product and re-engineer it with a CD model as the focus. A microservices-type design makes a lot of sense, where your application is broken into many components that can all be individually built, tested, and deployed to production. This loosely coupled architecture is not a new concept. Since the 1990s many companies have tried this with CORBA and Microsoft DNA models.  It is possible to do this with microservices, but it requires a major undertaking across the entire engineering organization and can take years to complete.

Automating deployment

You should consider release orchestration or application release automation to provide you with a holistic view of your pipeline. Maintaining visibility and control over your complex set of processes is challenging, but with enough oversight and the ability to analyze the big picture view and make changes to improve efficiency, you can get the most from CD.

Author
Kaushal Amin
Kaushal Amin is Chief Technology Officer for KMS Technology, a software development and testing services firm based in Atlanta and Ho Chi Minh City, Vietnam. He was previously VP of Technology at LexisNexis and a software engineer at Intel and IBM. You may reach him at kaushalamin@kms-technology.com.

Comments
comments powered by Disqus