Tracking change and innovation in the enterprise software development community
QCon London 2010!
March 10-12, 100
Speakers, 80 sessions,
"THE" team leads and,
architects conference.
Free Book Offer
SOA Demystified
$40 Value
Scaling Scrum
in the enterprise?
ScrumWorks Pro
can help.
Start a trial today
Posted by Dave West on May 15, 2009
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.
Agile Development: A Manager's Roadmap for Success
Learning to be a Good Product Owner: Foundation Skills
The 5 Mandates of Software Development Teams - Presto Manifesto
VersionOne is recognized by Agile practitioners as the leader in Agile project management tools. Companies such as Adobe, BBC, CNN, Dow, HP, IBM, Sony and 3M have turned to VersionOne to help deliver greater value to their customers.
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.
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.
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
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.
Brian Marick takes us through a quick tour of the most important values and challenges to adopting Agile successfully (they aren't the typical challenges and values we hear in the community).
The line between development and architecture is tricky. Does it exist at all? Is an ivory tower actually needed? There's a balance in the middle, but how do you move from developer to architect?
The word 'authority' sometimes produces an allergic response in hard-line agilists. Freedom and authority – both are bad if misused and both are good if used in right spirit for a noble cause.
"Getting Started with Grails" brings you up to speed on this modern web framework. Companies as varied as LinkedIn, Wired, and Taco Bell are all using Grails. Are you ready to get started as well?
Those familiar with only ITIL V2 often scoff at the thought that ITIL could serve as a governance framework for SOA. With ITIL V3, the focus of the framework shifted towards service-orientation.
SpringSource CTO Adrian Colyer discusses AspectJ, SpringSource's dm Server and tc Server products, OSGi and Scrum.
Heroku's Adam Wiggins talks about Rails, Background Jobs, Add-Ons, Ruby, and how Heroku manages to work around Ruby's inefficiencies using Erlang and other languages.
For Grady Booch the foundation of a good architecture is patterns, SOA being just one of many patterns. In this Second Life presentation, Booch attempts to bring more clarity on what architecture is.
4 comments
Watch Thread Reply