In our Agile Experience Report published on the Agile Alliance website I explained in detail how we learned to continuously adapt to new situations and learn from our mistakes. The document details our organisational and interpersonal practices. This is, for all intents and purposes, the social side of agile. But there is also a very important technical part we must take into consideration.

Without the tools and technical practices, agile is just a great story about some ideals. Organizing things is useless without the infrastructure to sustain the kind of work lean processes or scrum planning requires.

We at Syneto implemented a continuous integration and continuous deployment system. We even do continuous delivery inside our company. So what are all these tools about?

After a software developer finishes writing a small but functional piece of code, he or she saves the changes and pushes them to a central source code repository. This is something that can happen as fast as every couple of minutes or as rarely as once every couple of days. We usually commit and push once an hour on average.

Continuous Integration is a software development practice where members of a team integrate their work frequently, usually each person integrates at least once per day; leading to multiple daily integrations.

– Martin Fowler

We have another server continuously monitoring the central source code repository. Whenever new code is sent in by any of our developers, this server starts a process of integrating that new code. This is the continuous integration server. The code is checked out to another directory, all files are compiled and encoded, and unit tests are run. Other verifications, checking the graphical user interface and interaction with the underlying operating system are also run at this stage. This is a fully automated process and it exercises about 70% of all the paths in our application.

If all goes well, the continuous deployment process starts automatically. The end result of our build procedure is the Storage OS operating system with its hundreds of individual software packages. These must be constructed using our operating system’s package management system, called IPS.

The final step in our automated infrastructure is the continuous delivery process. This takes the IPS packages and makes them available on an update server. We only use an internal staging server, our end users do not get update every time we change our code. Even though it would be relatively safe to deliver continuously to end users, the storage appliance ecosystem is just too sensible for this kind of solutions. So before users get updates several other steps and tests are performed. But this is a topic for another blog post.