Last week, I described some of the Maven lessons and configurations we had used in the last while: Some useful Maven configs...
So now that you have all these Maven projects, local repos, well managed versions, unit tests, code coverage and static code analysis what do you do next?...
You run it all the time and you let everyone know how it is going...
Continuous Integration (CI)...
I am not going to go into too much detail about the concept of CI, Martin Fowler and countless others have already done that.
Martin Fowler - Continuous Integration
I will however ramble out some personal opinions of the advantages and challenges that come with CI and mention some of the tools out there. I say "challenges" because I don't feel there are actually any disadvantages with this approach, but rather it just illuminates some difficulties that always existed in software development.
The Advantages:
CI gives you an early warning of any major broken or conflicting code changes with continuous unit testing of all the changes, it enables better project visibility. Depending on thoroughness of your CI environment there can be immediate feedback to developers on the quality, functionality and state of the application. Bugs, systems issues and the time needed to correct them gets exponentially worse the longer you they go unseen and are left unattended. Another benefit is that there is always a "current" build, that can be used for anything like testing, demos or interim releases, so not only are the unit tests running all the time, functional testing can also happen on more current code.
After the initial setup and with having all the SCM integration, building, deploying and reporting automated it allows people to focus on what they actually should be and not constant "environment" issues.
The Challenges:
If CI is something new to the environment there will be some initial setup time / cost, including maybe some extra hardware as build machines.
I feel there need to be well developed, comprehensive unit test suites these are crucial if there is to be any benefit gotten out of the automated testing. With this need for comprehensive unit test suites there is a requirement for all parties involved clients, management and developers to understand that more upfront development time will be required and there will be long term benefits. What happens all too often as soon a deadline looms... all standards, tests and processes go flying out the window, and as soon as that happens there is generally never time to go back and fix it and those holes in testing and quality will remain in the system.
There is also challenges with large changes can be hindered by the constant builds although this can be be handled in a couple ways, depending mainly on how you handle your Revision control / SCM (source configuration management), but that is a subject for another day.
The Tools:
I am only listing the ones that I feel are probably the most common (in the java environment), and obviously all are free and open source. I was tempted to create a very scaled down & up to date version of: CI Feature Matrix, but when you get down to the details, the 3 tools below all do very similar things, and have very similar features. They all can run, schedule, build, notify, integrate with SCMs (CVS, Subversion, Git, Mercurial, StarTeam, ClearCase), graph and have plugins for pretty much everything you will ever need.
Hudson
Cruise Control
Apache Continuum
We have used Hudson for the last couple years, and a couple practices that have served us well are:
Ensure that a build can always be reproduced, the build must be a clean build from scratch and by that I mean all the code must code from your SCM tool.
Set up email notifications to all the developers, the architect/s, and the project manager or development manager of the project. That way everyone has an idea of what is going on... and sometimes us developers need a little "motivation". There are also RSS feeds available for all builds, failed builds etc. I personally use those rather than the emails... but that is purely personal preference.
Hudson needs a fair amount of disk space on large projects, to avoid issues midway in a project ensure you have ample space and keep an eye on the version / archiving settings.
There are plugins for all major IDEs that allow you monitor and control Hudson without opening a browser, I personally like having the Hudson build information available within my IDE.
Something I would have liked to have set up, is integration with a issue tracking system like bugzilla or something, but alas my little corporate doesn't work that way.
Thursday, July 22, 2010
Subscribe to:
Post Comments (Atom)
Popular Posts
-
I have recently been slacking on content on my blog, between long stressful hours at work and to the wonderful toy that is an iPhone, I have...
-
I make no claim to be a "computer scientist" or a software "engineer", those titles alone can spark some debate, I regar...
-
I saw an article (well more of a rant) the other day, by Rob Williams Brain Drain in enterprise Dev . I have to say, I do agree with some o...
-
This series of posts will be about me getting to grips with JBoss Drools . The reasoning behind it is: SAP bought out my company's curre...
-
Update: Check out my updated re-certification on the new 2019 exam... here Let me start by saying, for this certification I studied and...
Mua vé tại Aivivu, tham khảo
ReplyDeletevé máy bay đi Mỹ khứ hồi
có thể bay từ mỹ về việt nam không
có vé máy bay từ nhật về việt nam không
chuyến bay từ frankfurt đến hà nội
chuyến bay từ canada về việt nam
dat ve may bay tu han quoc ve viet nam
chuyen bay chuyen gia ve viet nam