Continuous Integration and Continuous Inspection as described in this book ideally bring together all components of the software system, source code and configuration alike, when a change set is committed to version control.
Continuous Integration automatically produces a known state of the software that can be verified using automated tests as well as static code analysis. When successful, the result of such a build, the build artifact represents a state of the software that is know to work correctly (at least all automated tests are satisfied) and can be made available for manual testing, for instance.
Continuous Inspection calculates software metrics that measure various aspects of the internal quality of the software for each build. Looking at this data over time faciliates a deeper understanding of the quality of the software throughout its lifecycle. This makes it possible to see trends and detect undesirable developments such as increasing code complexity as early as possible and to counter them before it becomes to expensive. The reports generated by Continuous Inspection can be used by the development team when explaining technical debt and the need for a refactoring to their management: "In the last sprint we did not develop any new features but we cleaned up our code base to eliminate duplicate code, reduce complexity, and fix coding standards violations as you can see in these charts. Thanks to this refactoring we will be able to deliver new features faster and more reliable in the future."
When you have followed the instructions provided in this book then you have a state-of-the-art Continuous Integration and Continuous Inspection environment for your PHP projects in place. This section will give you some food for thought with regard to additional measures that you should explore and might want to implement.
Modern version control systems such as Git make the work with multiple
branches efficient and simple. A common process when using Git is to
have two main development branches names master and
development that are used as follows:
master
There is no active development in this branch
There are no direct commits into this branch
Changes to this branch are only merges from the development branch (or from hotfix branches, see below)
The state of the software must be stable in this branch
development
This is the branch where active development takes place
It is considered best practice to develop new features in so called feature branches that are branched off of the development.
The state of the software may by unstable (for short periods of time) in this branch
When the time for a release has come you want to stabilize the state of
the software in the development branch and then
merge that branch into the master branch and create a
release tag there, for instance.
When a problem in the master branch is found the
developers should focus their efforts on fixing this problem. This
should happen in a hotfix branch that is branched off of the
master branch. Once the problem is fixed this hotfix
branch can be merged back into the master branch and
from there into the development branch. In case the
bug fix increases the technical debt of the project a new branch should
immediately be branched off of the development branch
in which the respective refactoring to clean up the code will take
place.
Both branches, master and
development should be continuously integrated. This
can be implemented by configuring two jobs in Jenkins, one for each
branch. These two jobs only differ with regard to the branch they
operate on.
While feature branches should be short-lived (to reduce the risk of
conflicts when merging them into the development
branch) it may make sense to also integrate them continuously. This can
be set up in such a way, for instance, that a script (invoked by hook in
the version control system or via a cron job) automatically creates and
deactivates jobs in Jenkins when a feature branch is created or merged
and deleted, respectively. Thanks to Jenkins' remote API this is can be
be implemented quite easily.