WHAT IS CONTINUOUS INTEGRATION
Continuous Integration is small pieces of effort to integrate source code at very regular intervals within a day by the development team with a view to avoid complexity of integration at the end, ensure good quality of code and reduce time taken to deliver it.
WHAT DOES CONTINUOUS INTEGRATION CONSIST OFF
The main aspects of a source repository are
- Define a well structured repository for your code
- Use a source repository tool like Subversion or Perforce or any others
- Ensure all the files are in repository than your local machines including libraries, IDE configs etc
- Be clear on Single repository or Branching (Single Repository preferred always)
Before you go about setting up your source repository ensure you have defined a logical or organized structure for your source code. You may want to put all your common code at single folder, user interaction code in one folder and likewise. There are many source repository tools in the market that can be used to store all your source code with necessary access permissions. Availability of open source tools makes life better than having nothing.
The biggest and common mistake that we all see is that team members trying to make changes on their local machines and not integrating with the main repository. Encourage all the team to put everything on the source repository so that issues like missing files, incorrect changes and others are prevented.
Often it is said that all changes have to be done on single repository, but in my whole experience i never came across a single company which did not feel the need to branch their code for one or the other reason. Although i would encourage making changes on a single repository as much as possible, have an alternate strategy to be ready to branch your code. Branching should be carefully planned with agreed strategy, branch naming conventions, checkin/checkout process, commenting formats, regular intervals to synchronize branch with changes in trunk and viceversa if possible. Branching does not add complexity if we stick to continuous synchronization with trunk and carefully planned.
- Key aspects of Build Process
- Ensure all files are checked into repository
- A build script is available or a build tool like Ant, Maven, MS Build
- A sensible build time of 10 to 15 minutes is achieved
- Build Automation
- Testing is done automatically as part of Build Process
The key pre-requisite for anyone to start a build is to ensure the all the files, libraries or dependent source code is all checked into source repository for a compilation and building the build. As Martin Fowler ones has written, “everyone commits every change, every commit on the trunk should be built”. It is very handy to use build tools like Ant, Maven or MS Build and many others rather than relying to do a build manually. There is every need to ensure the build process does not take more than 10 to 15 minutes to ensure the developer community does not spend all their time ensuring a successful build. Most projects does achieve this by using good tools available in the market.
It is a good practice to let automated build process test the build itself rather than any manual intervention. A good practice is to write unit tests using JUnits or any others and include them in your source to ensure they are built along with the source and the build is tested automatically and results published. All the tests pass indicates successful build.
- Build test results are published
- Latest build and build numbers are clearly communicated
- Automated notification before and after the build process
- Build failures analyzed for root causes and closed
A build process is considered good if there is a clear mechanism to communicate the start and end of build so the developer community can always take the latest changes into their local repository and test their own changes for any impact. Build results are communicated on a regular basis to ensure team are aware if a particular build has failed. Its often a good practice to identify the root causes of build failures and see if a review checklist is enriched to minimize failures for future.
Key Advantages of Continuous Integration
- Reduce code complexity and create more modular code by continuous integration
- Early identification of failures or broke code
- Immediate testing of all changes rather than leaving it until the end
- A stable build available at any given time
Disadvantages of Continuous Integration
- Takes time accept and settle down the build process
- Rich hardware might be required to achieve successful build process
- Well designed test suite to test the build always required
Continuous Integration allows to delivery software quickly and with minimal chaos towards the end. It may a bit time consuming at the start to setup the process and align the organization to follow but this is absolutely necessary to ensure we de-risk our development cycle from chaos and waste of valuable time. Suggest to go through following book for more details......