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:
- Subversion (SVN)
- Source Safe (from Microsoft) – now deprecated
- Team Foundation Server (TFS) (from Microsoft)
- GIT
- Mercurial (Hg)
- CVS – not recommended
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.