“You are working agile, are you using Hudson as well?”
This is a really good question that is coming – in some variations – from people which are interested in agile methods but not really knowing them too well yet.
But what is a good answer to this question? Simply“Yes!” would be a fact but not very helpful in the end. The more tool-oriented answer could be: “Yes, we are using Hudson, but we could be using Bamboo or Cruise Control as well.” Together with some lengthy explanation
why we decided in the end to use Hudson as a tool, which is to some extend personal preference as with most tools. Helpful? I do not think so! So let’s have a last try for some answer: “Yes, we are using Hudson as a part of our Continuous Integration environment together with a corresponding concept for SCM and automated tests.” Better, but there is lot more to tell on Continuous Integration and thus we are at the beginning of this small series of articles on this topic.
Continuous Integration – What, how and why?
What is behind the concept of Continuous Integration? Of course I could cite Wikipedia here, but anyone can take a look there anyway. And as this is supposed to give an overview on the topic it should not be too technical, that comes later. Thus:
Doing Continuous Integration means that all developers are putting together their code several times a day. By compiling all that code on some offical server – for example using the before mentioned Hudson – it is guaranteed that everything fits together. Automated tests ensure that everything works as expected. This whole process is running several times a day.
This sounds easier than it is. But before we are digging more into detail and the potential problems – or better challenges – let’s take a quick look at the question “Why?”. Why should someone introduce Continuous Integration in the development process of projects or products? Basically for agile projects this questions is not really valid as it is simply a must. Without Continuous Integration there is no chance to succeed in having those very short release cycles. Especially automated tests are very important here as it is the goal to have working software at “any moment in time” that could be delivered to a customer or at least presented to the customer. An additional positive aspect of this approach is that problems (e.g. in integrating) are realized much earlier in the project and can thus be tackled easier and more cost efficient. This leads us to yet another question: “Can we take Continuous Integration into use in non-agile projects (e.g. waterfall)?” The ideas are definitely useful and especially automated tests can help also in non-agile projects as the effort for testing might be too big otherwise at some point of time. But Continuous Integration is only showing its full potential in agile projects with the before mentioned short release cycles.
So we still have the question “How?”, which requires a more comprehensive answer that is given in the next paragraph.
Building a Continuous Integration Environment
An environment for Continuous Integration can get very complex depending on different factors like size of the project and team as well as the own demand towards the system.
“Broken Buidls”: It is impossible to talk about Continuous Integration without clarifying what is meant by a Broken Build. The term Build describes the comlete process in Continuous Integration of integrating and compiling code, deploying the new software and running automated tests. If only one of these actions is failing we are talking about a Broken Build, which is also called “The build is red”. In comparison we are talking about a “Green build” if everything works fine. A red build is an absolut alarming sign as it means there is no working software anymore and it implies that no one in the team is allowed to deliver new software unless this problem is fixed and the build is again green. How to handle broken builds for sure differs in different teams, but it is a plain fact that you are not doing continuous Integration if you are ignoring broken builds. How can anyone in the team check if new code is working properly if the current version of the software is anyway not working?
The following diagram shows an overview of a simple – but complete – environment for Continuous Integration. During this series it will be shown how to setup such an environment.
Having some experience one might be able to see one problem in the setup shown above. There is a lot of responsibility put on each individual developer to ensure that the build will not be broken. This means that ideally every developer must be able to run all tests – including integration tests – locally before committing any changes. I think this is fine for a small team of five to eight developers. Of course it is possible to scale a CI-System up and thus tackling those problems with a more technical approach. One possibility here is to setup a hierarchical build system, where developers are not directly committing to the product or project, but the code is verified in a Pre-CI-System. Only code that has been successfully verified there is committed to the final CI-System, where it is then tested again in the official build.
With such a system – that could be scaled up even further – it can be effectively avoided that individual mistakes of a developer directly lead to a broken build. On the other hand it is quite obvious that such a system is quite expensive in terms of money and man-power needed to setup and maintain the system. With the right mindset it is possible to have very good results as well with a smaller system I think.
Perspective
So far this was all theory and I want to cover the practical aspects of setting up a CI environment as well. Therefore the plan is to have a small series of articles and link those in below once they are done.
- Running reproduceable Builds using Subversion, Maven and JUnit.
- Executing builds automatically and deploying artefacts using a Hudson CI-Server.
- Introducing Integration Tests based on the Robot Framework .
Maybe one could say that the first step is obvious, but I think it makes sense to really start from scratch here. Once the second step will be finished there is already a working CI environment available. With the third step this will then be enhanced further showing how to run integration tests using the Robot Framework as an agile testing tool.
Was this post helpful?
More articles
fromThomas Jaspers
22.2.2019 Your job at codecentric?
Jobs
Agile Developer und Consultant (w/d/m)
Alle Standorte
More articles in this subject area
Discover exciting further topics and let the codecentric world inspire you.
Gemeinsam bessere Projekte umsetzen.
Wir helfen deinem Unternehmen.
Du stehst vor einer großen IT-Herausforderung? Wir sorgen für eine maßgeschneiderte Unterstützung. Informiere dich jetzt.
Hilf uns, noch besser zu werden.
Wir sind immer auf der Suche nach neuen Talenten. Auch für dich ist die passende Stelle dabei.
Blog author
Thomas Jaspers
Do you still have questions? Just send me a message.
Do you still have questions? Just send me a message.