Home

News: The Road to Build Enlightenment

Bookmark and Share Get thread feed

  1. The Road to Build Enlightenment (13 messages)

    • Posted by: Regina Lynch
    • Posted on: August 24 2006 12:10 EDT
    For developers, build system development and improvement is not often a high priority. Energy must be devoted to the software itself. However, Jason Sankey argues that a better build system will save time in the long run. This article walks through required properties for an effective build system. Basic necessities, according to Sankey, include machine independence, scripted builds, scripted tests and regular builds. But to take it to the next level, build systems should focus on continuous integration, automated releases and building in multiple environments.
    Once you have the facility to perform regular builds, a natural question is how often you should execute the build. The answer is simple: as frequently as possible. One particularly useful way to schedule automated builds is whenever a change is committed to the source control server. This facilitates early feedback when a change breaks the build, allowing the problem to be addressed immediately. The longer a build breakage goes unnoticed, the more team members will be affected, and the harder it will be to track down the change(s) that caused the problem. Scheduling builds in this way is one of the core practices of continuous integration. I strongly recommend that you read the original article by Martin Fowler, which both gave a name to and helped popularise this practice. Key Benefits: Even earlier feedback - tracking down the change that caused a problem becomes trivial. Developers check code in and out with confidence. Challenges: Long build times - a long build is the enemy of fast feedback. Consider breaking larger projects down into dependent modules that can be built and tested quickly. Split test suites so that fast tests are run every build and slower tests only run overnight. Use incremental builds throughout the day and full rebuilds overnight.
    For "extra credit," Sankey's most effective build system would also include static and dynamic analysis.
    After the initial setup cost, an effective static analysis tool will easily pay for itself by detecting problems early in the development process...[dynamic analysis] is especially useful for identifying sections of your code that need further testing.
    In addition to Sankey's list, what requirements would you have for an effective build system? Do you agree with the importance of an improved build system in the development process?
    Reply to this

    Threaded Messages (13)

  2. Re: The Road to Build Enlightenment[ Go to top ]

    This says nothing more than Fowler's original CI writeup. Overall it's a big waste of time because IT'S A PRODUCT ADVERTISEMENT.
    Reply to this Reply to original

  3. Re: The Road to Build Enlightenment[ Go to top ]

    As opposed to all other posts on theserverside...? Slight sarcasm aside, if I were to be idealistic for a moment, I would make a wish for a discussion Java forum/community devoid of both (not so well) hidden product advertisement and product-religious flame wars, but since I'm a hardened cynic, I realize that there is too much financial interest and ego embedded in the products and frameworks in question to make it any more realistic than a kid hoping to get a real pirate ship for Christmas. Then again, if someone were to prove me wrong, I would be (nearly) eternally grateful.
    Reply to this Reply to original

  4. Re: The Road to Build Enlightenment[ Go to top ]

    While we may never achieve the pirate ship in the real world, I fully support the dream and the vision of the pirate ship.
    Reply to this Reply to original

  5. Read the original source: Fowler's "Continuous Integration"[ Go to top ]

    As it even says in the article: "I strongly recommend that you read the original article by Martin Fowler, which both gave a name to and helped popularise this practice." So skip that b.s. and just read Fowler: http://www.martinfowler.com/articles/continuousIntegration.html
    Reply to this Reply to original

  6. We already have such an open-source system![ Go to top ]

    It's called CruiseControl: http://cruisecontrol.sourceforge.net/
    Reply to this Reply to original

  7. Re: We already have such an open-source system![ Go to top ]

    https://hudson.dev.java.net/ is another great build system, really easy to set up, supports multiple projects, CVS SVN Maven ANT etc, publishes releases changelogs unit test results etc, can do scheduled or trigger builds. really excellent I cant see a commercial product competing with these if they are just repeating Martin Fowler, they will need to change the game
    Reply to this Reply to original

  8. Re: We already have such an open-source system![ Go to top ]

    I cant see a commercial product competing with these if they are just repeating Martin Fowler, they will need to change the game
    Agreed. The difference between most of the successful commercial products and something like CruiseControl is an effort to go beyond CI (or continous feedback) and put more effort into managing and tracking releases. The other big difference is that many of the commercial tools are making an effort to manage multiple machines. While Cruise is making inroads towards the build farm, last I checked it's still mostly targetted at one integration server. That's good enough for a small or medium sized team that just needs regular feedback about the condition of the build, but there's room for improvement. CI is really a pretty easy problem to solve. We had Cruise and Anthill five years ago and another (timberbox?) well before that. Careful release management, advanced reporting, automated promotions and deployments, build farm management, etc.. those are the more interesting topics today. Pulse does have the ability to use pulse on the dev's machine, which is interesting. I still haven't had a client ask me for it, and I'm not sure why it's terribly useful, but it's interesting from a consistent process perspective. There are some other features that look nifty and other decisions I'd take issue with, but it's not really fair for me to pick on them here. I think we're cruising at nearly double digit numbers of commercial build management tools now. We all agree there's a market but with the quality of the competition and the dozens of open source tools out there, there should be a shake out. Trust me that there are players out there trying to change the game. Anyway, I should get back to that :)
    Reply to this Reply to original

  9. Re: We already have such an open-source system![ Go to top ]

    I think CI changed the game. To the point where even if the project has just a single developer, its worth having the project formally implement CI using the organizations shared build process/server(s) for publishing builds. We've used CI for a good few years and the payback is huge, no more fingers being crossed when a release is built, no more "Well it worked/built on my machine", predictable improvement of product as build numbers increase etc.. etc.. But whats next? Builds can automatically generate differences/changelogs. Some best practises/standards can be implemented to have meaningful extractions of changelogs from bug reporting or source control systems. What would be usefull is an open set of standards for exchange of version information between between software development systems. Example, an XML/RSS feed between two versions (tags/checkpoints) on the version control system, or a feed to the bug reporting system so the new default for QA is the 'current' released build. Or a mapping between the developers set of comments and a filtered piece of text that can be used in release notes, and remembered for subsequent builds. Something standard and independent of the specific toolsets whether they are Eclipse, JBuilder, Rational, ANT, CVS, SVN, VSS, bugzilla, JIRA ... whatever. A standard even if its de-facto, like JUnits XML unit test results, allows toolsets to add value e.g., publish nice graphs showing unit test trends. Something that means you dont have to change your entire organization to use Rational, Visual Studio, or whatever is the latest propiertary technology to make the next step forward. Dont get me wrong, The payback is probably greatest for the first steps, with predictable builds, automated tests and some manual integration between systems... but are there any interesting standards/projects related to the next steps that we should look at?
    Reply to this Reply to original

  10. Re: We already have such an open-source system![ Go to top ]

    ... but are there any interesting standards/projects related to the next steps that we should look at?
    Yeah, the Eclipse ALF (Application Lifecycle Framework) project is pretty interesting. The focus is on gettting various tools to provide semi-standard SOA interfaces so that it is relatively easy to get various tools to talk to each other. That opens the door to nice tool to tool integration. ALF also provides a service flow feature to allow users to script commands to tools in response to events in other tools. Getting test tools, bug tracking, source control, and build all on the same page is important and something industry players care about even if we're not doing well at making it happen yet. Seeing some open source projects (svn is somewhat involved) join ALF might be nice..
    I think CI changed the game. To the point where even if the project has just a single developer, its worth having the project formally implement CI using the organizations shared build process/server(s) for publishing builds.
    Definately, but I think when a single developer is doing that, they are just implementing some build management and continuous feedback. An easy trap to fall in to is to believe that once an organization has installed something like Cruise they 'have CI'. They don't. They have an application running builds and sending out feedback regularly. CI requires that developers are checking in regularly, don't tolerate a broken build, etc. All a tool can do is make it easier to implement a good process (I hate that word) but at the end of the day, the development team is either integrating continuously or not. Tools aren't required.
    We've used CI for a good few years and the payback is huge, no more fingers being crossed when a release is built, no more "Well it worked/built on my machine", predictable improvement of product as build numbers increase etc.. etc..
    I hear you. Actually, we're starting to think that the whole concept of a 'release build' is a bit silly. Pretty much anything built on the authoritative build machine should be able to be converted in a release build. How do you know it's time to do a release build? When the developers claim some set of of build artifacts contain all the fixes for the release and QA doesn't disagree. You could go back and run the release build process against some source control tags, or have check-in freezes, but what you really want to do is run another process to make the set of artifacts that you already have and have tested into a release. I'll stop here before I turn this into a product advertisement :)
    Reply to this Reply to original

  11. Re: We already have such an open-source system![ Go to top ]

    Thanks for the pointer to Eclipse ALF. Hopefully other OS projects will start to support the services defined in ALF, it would be fantastic to have the services defined in the ALF vocabulary for SCM & build, maybe even requirements mangement, test results... +10 on the other comments. Apart from the anything else publishing regular builds stops stuff like this from happening :) Dont stop, turn it into a product advertisement :) it looks like a very interesting project and well worth its own article on TSS. In an age when there are dozens of web application frameworks, its great to see a problem that needs to be solved getting the attention it deserves. It would be great to have "Must integrate with Eclipse ALF" as a selection criteria for enterprise application development infrastructure & tools. Thanks again, Garry
    Reply to this Reply to original

  12. Re: We already have such an open-source system![ Go to top ]

    Dont stop, turn it into a product advertisement :) it looks like a very interesting project and well worth its own article on TSS.
    We've had bad luck submitting stories. Hopefully when we do our full 3.0 release it will be deemed as important as the quarterly releases of products with less users. :) C'est La Vie.
    It would be great to have "Must integrate with Eclipse ALF" as a selection criteria for enterprise application development infrastructure & tools.
    I agree. I think the vocabularly aspect of ALF has a lot of promise. I'm less convinced about the BPEL scripting, but hopefully that will find an appropriate role. We're still a long way from seeing ALF really up and running, but there are working groups working and a couple vendors putting together early web services.
    Reply to this Reply to original

  13. build manager[ Go to top ]

    For developers, build system development and improvement is not often a high priority. Energy must be devoted to the software itself. However, Jason Sankey argues that a better build system will save time in the long run.
    For developers, build system development and improvement shouldn't even be a priority. It's the responsibility of the team manager/leader to ensure that the build system is effective. Granted, s/he may allocate (developer) resource to the task of setting up a build system and then maintaining it, but it certainly shouldn't be something developers have to worry about in order to get on with their jobs... which is developing software. Even better; if appropriate to your organisation's profile, you could hire a build manager who is responsible for making sure the continuous build system runs and is updated as required, and possibly even deploys code to other environments and versions it, thus taking this kind of worry away from the developers - who have plenty of other things to worry about!
    Reply to this Reply to original

  14. Re: build manager[ Go to top ]

    ...it certainly shouldn't be something developers have to worry about in order to get on with their jobs... which is developing software...
    ...which sometimes (on our project) seems not to build, run or do what it's supposed to anywhere outside the developer's box (or mind)! In the last two years, nothing has contributed more to our ability to deliver value to our customer than CI and improving our build/deploy/test/promote cycles. We do find now that we haven't done all we could, so we are going back to the build system now to up our game.
    Reply to this Reply to original