the 12 steps of continuous integration - logit blog

//

The 12 steps of Continuous IntegrationPosted on February 2, 2014 by Marc Jacobs

A startup always starts with a good idea. A few people got an

idea and are so eager about it that they want to give it a

chance. After doing some research they find out that the

idea, an application, is indeed a one-of-a-kind and it’s

potentially sellable. The group starts programming and within

two months the first version of the application is released.

The community is reacting enthusiastic on the trial version of

the software and there are already some buyers. The

contacts with the community are good and bugs are fixed

almost immediately. Meanwhile, a lot of new ideas are popping up and the application is

evolving. The project members are popping champagne bottles and celebrate… too early. In

this blog post I will tell you all about continuous integration which will get your software to the

next level.

A lot of startups with potential are celebrating their succes too early…

Because of its evolution the software is getting more complex. More bugs are popping up

and when some part of the application is fixed another part is suddenly bugged. The project

members have their hands full fixing the broken parts, buyers are requesting more and more

new features and the pressure of the community is rising. Deadlines and promises are not

met and the programmers are getting demotivated. The once so great idea is turning into a

disaster.

The phase right after the startup is the one where a software startup often fails. There are of

course a dozen of possible causes. For example, the testing of the software is done

manually by the programmer all the time, but because this is the boring part of programming,

it is often skipped. Because the software is so complex, quality assurance is now taking a

great amount of time, but it seems to be less important. But it is important. Maybe the most

important. Popular management philosophies like Lean and Agile dictate it for you: stop the

process workflow, first remove the bottleneck. In this particular the lack of Quality Assurance

Logit BlogBetter log it than lose it

The 12 steps of Continuous Integration - Logit Blog http://www.logitblog.com/?p=2722

1 of 4 07-02-2014 09:47

is the bottleneck. So let’s remove it by automating the boring test process and start

Continuous Integration.

I created a series of 12 steps that hopefully helps you to take testing to another level. This

process is often called the development pipeline where you put in the source code of your

application at the beginning and receive a potential releasable package at the end.

1. Version management

Many developers are using version management tools like Git or Subversion. It often

happens that developers don’t respect the guidelines of building a repository. They just use it

as a backup method. Don’t do that. Your trunk is your holy grail. Keep it as clean as possible

with only source code and configuration files. Don’t add large third party setup files or

additional content like movies or photo’s. The trunk should always contain the latest healthy

code that works when it gets checked out. There are many guidelines available online which

can help you how to create your repository.

2. Decide a development strategy

Decide what kind of development strategy you want to use. For example, SCRUM or

Kanban can be used to develop in small increments and integrate perfectly with Continuous

Integration. When you choose a development strategy make sure everybody understands

and accepts the strategy. When this is not the case it is likely that the process is disturbed

because of communication problems.

3. Decide your delivery strategy

Depending on what you are building, you choose a delivery strategy. The delivery is the

result at the end of the development pipeline. Continuous Delivery is ideal for application

development: the result can for example be an installation package which directly can be

delivered to the QA tester or customer. It also can be used in web development where the

result can be an update in the acceptance or production environment.

4. Decide an application version strategy

The version of your software communicates the changes and is normally used to inform your

clients of the latest updates. In large projects an example of a version number with four

digits, like 5.1.2.276 can be:

5 is the application version, which means version 6 will be a complete rebuild

1 is the marketing version, which can be used by marketing to announce some new

features

2 is the minor version, which is used every time there is a new release. This contains

for example bug fixes and minor features

276 is the build or revision number, which will increment every change in repository or


2 of 4 07-02-2014 09:47

every new build

5. Build automation tool

The build automation tool is the dashboard of your test automation and the place where all

the dots are connected. It basically consists of build steps. Every build step can execute its

own separate piece, like running a Powershell script or invoke a checkout of the trunk. The

build automation tool keeps track of the status ever build step returns. If all the build steps

succeed, there will be a new potentially releasable software package. Examples of build

automation tools are Ant, Phing (commandline tools), Jenkins, Team Foundation Server and

TeamCity (Web based GUI tools).

6. Create and implement unit tests

The basis of testing your software is unit testing. This means testing your methods and

classes independently. PHPUnit and MSTest are some examples of programs that can

execute unit tests and can be invoked from a build automation tool.

7. Automatically build a test environment

To make sure your software is working correctly you need a test environment with your latest

version of the software. The ingredients used to create such an environment are: compiling

and building the latest source code (checked out from the trunk), add external content (like

movies or third party tools) and configure the environment (like configuring Windows registry

settings). At the end you should have a test-ready environment, build from scratch.

8. Automatically test your most precious software parts functionally

Try to find the core of your software and make sure all functionalities are tested on the test

environment you created in the previous step. Simulate a user clicking through the

application. Software like Selenium (for web apps) or AutoIT Scripting (for Windows apps)

can realize this. It’s impossible to test everything, so try to find the most important spots of

your app. It is recommended to create a “Happy flow” that follows the path of a user that

always chooses the right options. From there on you can expand your tests incrementally as

your software evolves. To reduce the build time it is also recommended to functional test in a

parallel way.

9. Optionally create an acceptance environment

If all functional tests are succeeded, it is possible to create an acceptance environment

on-the-fly. This environment can be used for some additional manual testing. For example

the Product Owner or QA department can use this to accept or decline a feature.

10. Optionally create an installation package

All tests, both unit and functional, are succeeded. This means your software meets most

likely the most important quality requirements. At this point it is save to create a software

package of the newest release. After the package is created, it is potentially shippable. The

choice can be made to do some manual acceptance testing (on the environment created in

the previous step).

11. Create some error reporting

If a test fails it is important to get feedback, so you can debug the error. By creating a


3 of 4 07-02-2014 09:47

Follow

Follow Logit Blog

Get every new post delivered to your Inbox

Share this on:

screenshot on error and add an error log and put these on a central place on the network, it

will make life much more easier to find the solution for the error. The solutions from step 5

has notification systems to inform the team or individual when a build or test fails or

succeeds.

12. Backup your Build Automation

Because your build automation ensures the quality of your product, it is promoted to be

marked as important as well. That it is why a backup task should be created of the build

automation logs and configuration. Also don’t forget to install a virus scanner if you use a

build automation tool on a Windows environment.

Hopefully, the twelve steps above will move your software to a whole new level. My

experience is that at first CEO’s and CTO’s don’t like the idea above, because it sounds

expensive and time consuming. But when bugs are piling up and developers are getting

demotivated, there seems to be no way out. Afterwards, those CEO’s and CTO’s cannot

imagine to live in a world without build and test automation. Humans make mistakes, so

automate your tests and ensure your quality, because quality is the first step to the road of

success.

If you have any questions or comment please leave a comment below.

This entry was posted in Development and tagged Agile, Ant, CI, Continuous Integration,Development, Jenkins, Kanban, Lean, Phing, Scrum, TeamCity, TFS by Marc Jacobs.Bookmark the permalink [http://www.logitblog.com/the-12-steps-of-continuous-integration/] .


4 of 4 07-02-2014 09:47

the 12 steps of continuous integration - logit blog

Documents