Article: Where To Now With Build Automation

Posted by Dave West on May 15, 2009

Sections

Process & Practices,

Operations & Infrastructure

Topics

Agile Techniques ,

Agile ,

Architecture ,

Build systems

Tags

Best Practices ,

Deployment ,

Atlassian ,

Continuous Integration

This article, by John Smart of Atlassian, discusses four aspects of continuous integration and automated builds that offer the potential to increase the utility of these common agile practices.

An effective Continuous Integration environment can save your team time, money and even existential angst. It can enable bugs to be discovered earlier, their cause identified more easily, and ultimately get them resolved more efficiently. It can encourage better source code management practices, help you leverage automated analysis tools, encourage better testing, track your progress and remove bottlenecks from your developers lives. It can facilitate the deployment process, and make your releases go more smoothly and more reliably. Managers will have more charts than they know what to do with and developers will be happier. To put it another way, not using Continuous Integration is like developing software using Notepad, it's possible but it's horribly inefficient.

 

Continuous communication flow, effective build process, code quality, and automated deployment are the four issues covered in this article.

Read John Smart's Where To Now With Build Automation? - The Future of CI Best Practices, contributed by Atlassian Software, to better understand this topic.

1. Back to top

   Improving the compile and link process is key to improving CI Builds

   by tracy ragan

   Great explanation of how Continuous Integration is used for managing a workflow. But, that is not all that a CI process should do.
   
   The term "build" in this article describes workflow - not the compile and link process. To most developers a build is the process of converting source code into binaries. Then there are the pre and post steps around the build like check-out and testing. I call that the workflow component of CI.
   
   Builds are slow because the scripts that support the compile and link process are often times highly redundant, manual, out of sync with IDE builds, and not capable of running in an incremental mode. It is my experience that if you want to gain speed in your CI process, the lions share of the problem is in the time it takes for the compile and link process to execute. Improving the compile and link process allows for the "build" to support frequent agile iterations whereby only updated source code is re-compiled. This moves the 1 hour+ builds down to literally only a few minutes and also allows for the support of pre-commit or pre-flight builds.
   
   The ability to improve the compile and link process should be core to any continuous integration solution - after all the point is to "integrate" continuously and the only way that integration is done is if the application source code is compiled as a complete unit. Workflow is simply icing on the cake that supports the core activity of the software build.

   Reply

2. Back to top

   Selective testing can also have significant impact on build efficiency

   by Ken Olofsen

   I'm with Atlassian and it's worth noting that Clover also provides Test Optimization, or selective testing, which automatically determines which tests to run based on the code changes made for the particular build. This can provide significant time savings allowing build process to run more frequently, especially for functional test suites that often take much longer than unit tests.

   Reply

3. Back to top

   With an eye toward continuous communication flow...

   by Sean Blanton

   I'm glad to see the emphasis on communication and have been exploring that aspect as well.
   
   Text messaging and particularly Twitter-like tools provide a more direct, convenient and efficient means of notification. Here is that post: Build Management 2.0 - Messaging

   Reply

4. Back to top

   E-mail, IM and scripting tools

   by Daniel Sobral

   I'm deeply unconvinced about the arguments about IM. First, integration tests are slow, so the programmer is hardly waiting for these results. He is onto something else, so the gain of 10-15 minutes after the slow integration test is hardly relevant. Furthermore, if you need 10-15 minutes for an e-mail to propagate all the way to client, you have a deficient setup which should be fixed instead of being worked around. The same goes for mobile phones which don't receive e-mails automatically.
   
   
   
   On the plus side of e-mails, it doesn't intrude on a programmers flow. E-mail clients can be configured to alert or not depending on many criteria, and this can be changed at will according to the programmers necessity.
   
   
   
   Now, about scripting tools, another recent option is SBT, which is a build tools on the lines of Maven, though simpler, and which uses code in Scala - a JVM language -- instead of XML as its configuration language.
   
   
   
   Overall, and e-mail vs IM notwithstanding, this was a good article.

   Reply

• Older >