State but is usually not. Compiles are executed as needed in the IDE. Some SCM tools actually interact with the file systems on the developers' PC so that CIs remain in synch with the Development State. Developers quite often use an IDE to create a virtual development environment to produce and unit test their code. Many SCM tools today also have integration features with popular IDEs that enable easy Check-in and Check-out of CIs from and to the SCM tool. Once the completed changes or new CIs are officially
Checked-in to the Development State, they need to be compiled and unit tested with other CIs from other developers' changes. The yellow triangles represent this incremental compiled code. The compiles at this level are usually done on an ad-hoc basis driven by the needs of the development team.
The Integration State is similar to the Development State with two important differences:
- It provides developers access to a larger set of system resources. This could include Web servers, Application servers, Databases, and a wider pool of developers' code that have been promoted to the Integration State.
- It does not allow Check-out or Check-in. This is because we do not want any new CIs or CI changes to creep into the SCM system without going through a Change Control first. This concept is key to the integrity and stability of the following States and the CIs stored within them.
The Integration State facilitates the next stage of testing, Integration testing. This is a view-only State where Developers, Managers, and CCB members can only see the source CIs and the complete compiled Application (indicated by the yellow octagon), but not alter
its composition or interact with the source code. The need for developers to move source code and other CIs freely between the Development State and the Integration State
is indicated by the lack of a CCB and approval step. CCB approval cycles prove to be extremely cumbersome in today's iterative, rapid development styles. To move CIs out of the Integration State to the Quality Assurance (QA) State, CCB members must review both the changed/new source code and other related CIs as well as the compiled versions of the changes that impact the Application at this point in the lifecycle. This is a unique
perspective as the CCB members are looking at both these CI types (source code,
compiled code, and any other CIs relevant to the change in the Application). After this review, these CIs are formally approved or rejected by the CCB and if approved, promoted to the QA State. If problems are found, the CIs are demoted to the Development State
where a Manager evaluates the error(s) and decides what corrective actions to take. This could include demoting the CI to the Development State to perform a checkout to modify the code(s) causing the error and then promoting it back to the Integration State, creating new versions of the CIs, promoting and replacing the CIs that were causing the problem, or possibly other CIs need to be changed that interact with the problem CIs.
The Quality Assurance (QA) State is where the QA group is going to be involved with a much different set of activities. This is also a "view-only State" where the QA group is focused on the compiled Application (indicated by the yellow octagon). The source code is present only to build the run-time Application. The QA group is a independent team that takes a fresh look at specific areas where changes have been made, as well as interactions with the complete Application. The QA team is usually responsible for creating test cases that will validate the quality of the Application. They may also
perform requirements validation. This is the process of making sure that all requirements
defined for the Application are tested. Finally, a CCB is performed to officially approve the changes. As