May 23, 2014

Continuous Integration

Code repository, automated build and continuous deployment

How it all works

All code for a project is stored in a code repository. Developers get code out of the repository, work on it and then put it back. A number of things can then check the code for quality, standards and test coverage. The solution can then be deployed onto test servers and integration and acceptance tests run against the interfaces. Documentation can be automatically generated describing the code and the metrics for all these automated processes.

 

Code repository

A code repository is a place that developers can store their code and share changes with each other. Repositories have many features which enhance the ability for developers to work together including merging changes when two or more developers have worked on the same file at the same time, backups, branching, labelling and rolling changes back to a previous state.

There are a number of popular and well used repositories in the finance sector and these are:

It is not necessary to know how to set these up or how to use them as part of your training, however, as a developer you will certainly use one of these as soon as your start coding, so it won’t hurt to read about them in advance.

 

Adding code to the repository

When the developer has finished editing the code, they will submit / sync / check-in their code into the repository. The different terminology comes from different repository systems.

When this happens, if the team has set up ‘gated check-ins’ the check-in process will analyse the code to ensure it meets the criteria for being able to check-in code. Some criteria may be:

  • The code compiles
  • That unit tests all pass
  • Certain coding standards are met

There are many other criteria a team can set.

 

Automated deployment

Once the code has passed the gated check-in, the code can be automatically deployed onto a single or set of test servers. Integration or acceptance tests can then run against the deployed code. This usually happens asynchronously from the check in, so it is possible for the developer to successfully check in code but it fail the acceptance tests.

For this reason, a report of the test results is usually made very visible to the team to provide immediate feedback. This can be in the form of a monitor in the development area, notification messages in the taskbar or emails.

 

Documentation

As part of the BDD process, it is also possible to produce live documentation about the code. This can happen automatically through this process. Please see the BDD page for details.

Simon Powers
Simon Powers is an Agile Coach specialising in large scale transformations and agile adoption. He has a background in very large enterprise architecture which has led on to organisational design and agile process refinement. Simon is the founder of Adventures with Agile.