The main purpose of Staging of the Build is to get faster feedback from the Continuous Integration System. A programmer cannot wait for more than 2 hours to get feedback about the check-in. So the Build is distributed in various stages to ensure faster and step by step feedback. This is applicable for typical teams maintaining (or going to maintain) larger code and test code base. Following are the various Stages.
- Once the programmer checks-in the code, the Inspection and the Commit Build can be parallely triggered. In the Inspection Build, the tools related to Code Complexity of Code and Test Code, Static Tools and other Inspection Tools like Design Validation , Architecture Validation etc. can be run. Commit Build should give feedback in less than 10 minutes. If teams can get feedback in less than 5 minutes then it is great result. The important point is- teams should try all possible means to get faster feedback from the commit build.
- If the Commit Build is Pass, then the Stage 2- Secondary Build is triggered. In this Build , the Longer running Integration, Component and System Level Test Cases are run. Typically the thumb rule is to get the result from the secondary build in less than 2-3 hours. To get this result we can run the Build in a Cluster Setup as shown in the Figure above.The inspection build may take longer time based on the different tools being run. Teams can decide to fail the build based on analysis of the report.s For example if the Static Code errors are introduced in the new build then immediately the secondary build can be stopped.
- Once the Secondary Build is Pass, the Non Functional Test Build can be triggered. This comprises of Reliability, Availability, Volume, Stress, Performance Related Test Cases. These test cases takes much longer time and it depends upon the kind of System under Test and the related Test Cases that are being executed.
- Further Stages can be added depending upon the need and also based on the kind of system.