|
Sponsored Links
Resources
Enterprise Java
Research Library
Get Java white papers, product information, case studies and webcasts
|
News
News
News
|
Messages: 13
Messages: 13
Messages: 13
Printer friendly
Printer friendly
Printer friendly
Post reply
Post reply
Post reply
XML
XML
XML
|
 |
The Road to Build Enlightenment
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?
|
|
|
Message #216444
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: The Road to Build Enlightenment
This says nothing more than Fowler's original CI writeup. Overall it's a big waste of time because IT'S A PRODUCT ADVERTISEMENT.
|
|
|
Message #216447
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: The Road to Build Enlightenment
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.
|
|
|
Message #216493
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
build manager
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!
|
|
|
Message #216495
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: We already have such an open-source system!
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
|
|
|
Message #216504
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: The Road to Build Enlightenment
While we may never achieve the pirate ship in the real world, I fully support the dream and the vision of the pirate ship.
|
|
|
Message #216519
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: We already have such an open-source system!
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 :)
|
|
|
Message #216545
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: build manager
...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.
|
|
|
Message #216585
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: We already have such an open-source system!
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?
|
|
|
Message #216602
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: We already have such an open-source system!
... 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 :)
|
|
|
Message #216627
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: We already have such an open-source system!
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
|
|
|
Message #216775
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: We already have such an open-source system!
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.
|
|
|
| New content on TheServerSide.comNew content on TheServerSide.comNew content on TheServerSide.com |
|
|
Reza Rahman explores the features of the proposed JSR 299, Contexts and Dependency Injection for Java EE (CDI). When approved, it promises to be a key feature of Java EE 6.
(November 2, Article)
SAML is an XML-based standard for exchanging authentication and authorization data between security domains. The single most important problem that SAML was created to solve is the Web browser Single Sign-On problem. Many organizations are debating whether to stay with version 1.1 or move to 2.0. This article makes observations about both options.
(September 28, Article)
Joe Ottinger takes a look at how people learn, and applies it to the practice of programming. He notes that understanding how people learn is an essential part of working in a programming team.
(September 22, Article)
Stephen Maryka gave us an article about the Asynchronous Web and posed a number of questions that get examined like an approach to delivering Asynchronous Web capabilities through extensions to existing Java EE technologies.
(July 14, Article)
JavaServer Faces Flex goal is to provide users capability in creating standard Flex components, part of flexSDK which is open sourced through MPL license, as normal JSF components. This article by Ji Hoon Kim will provide an overview of creating a simple multilingual JSF page consisting of JSF Flex tags.
(June 29, Article)
In this session Jeff explores the key characteristics of successful SOA projects. He covers some of the patterns, and anti-patterns, tool sets, and strategies that he himself learned the hard way. Last, he provides a strategy and blueprint for achieving a high likelihood of success in your SOA project.
(June 23, Tech Talk)
Ari Zilka, CTO of Terracotta, Inc., talks about the new features in Terracotta 3.1, announced during JavaOne and available now.
(June 15, Tech Talk)
In this Tech Talk, Josh Long explores an integration challenge using Spring Integration and walks through the implementation, employing and expanding on the basic patterns of Enterprise Application Integration to tie together components into a function integration solution, and then demonstrates how Spring Integration helps address the integration requirements.
(June 15, Tech Talk)
In this Tech Talk, David Geary teaches you: The basics of Google Web Toolkit; How to implement Ajax-enabled applications in Java; Internationalization; Hooking into the browser history mechanism; Remote procedure calls.
(June 4, Tech Talk)
Jon Kern discusses the best architecture/technical solutions and ensure that they are repeated by all developers. By tackling the architecture up-front in a serial manner, subsequent parallel development will be much more manageable and predictable.
(May 28, Tech Talk)
This keynote describes the frustrations of modern knowledge workers in their quest to actually get some work done, and solutions for how to guard yourself against all those distractions. Neal Ford talks about environments, coding, acceleration, automation, and avoiding repetition as ways to defeat the misguided attempts to sap your ability to produce good work.
(May 26, Tech Talk)
Gil demonstrates how new, aggressive uses of already abundant compute capacity by common applications offer competitive value for application designers.
(May 21, Tech Talk)
Chris Keene introduces WaveMaker as a new way to automate the ability to generate Hibernate classes in order to more quickly bring OR mapping into an application.
(May 19, Article)
In this session Nati Shalom demonstrates how to take a standard Java EE web application and scale it out or down dynamically without changes to the application code. Seeing as most web applications are over-provisioned to meet infrequent peak loads, this is a dramatic change because it enables growing your application as needed, when needed, without paying for unutilized resources.
(May 19, Tech Talk)
Mastering EJB was one of the original and most influential EJB books in the industry. Mastering EJB III now returns with two new expert co-authors, updated for EJB 2.1 and 30% new chapters including security, integration, best practices, open source, and more.
(Book PDF Download)
The Application Server Matrix is a detailed listing of J2EE vendors and their application server products, with information on latest version numbers, J2EE spec support and licensing, pricing, platform support, and links to product downloads and reviews.
(Application Server Comparison Matrix)
|
|
