In Apiumtech took some time riding what is known as continuous integration and after more than 50 projects in the last 2 years, I would like to present some conclusions. The main purpose is to try to clarify concepts.
First of all, to correctly define the term “continuous integration” and all its implications let’s look at the political branches:
Continuous integration is just all work on the same branch.
This point tends to generate much controversy, especially because there are a lot of literature that supports the opposite. (Read github and policy branches master / develop , or, for example, different strategies proposed branching Microsoft )
The advantages of working in one branch are, a priori, the following:
- The team always works on the same version, the “merge” is not so frequent and when there is low cost.(Remember that no conflict of text in the merge does not mean that the functionality is free of errors)When working in branches, working on something that is not real in its entirety.
- The master branch “always works.” This is commitment. The decision to make it a release or climb or not to prod, is unrelated development, as it should be.
- The code is actually shared. Within a development team, the “team culture” or agile concepts such as Code Ownership or Shared Architecture are desirable and even necessary to very basic level, without this there is agile.
- The build runs on all machines.
- The feedback is ultra-fast. (When someone breaks something team, we know at the time)
This is not to say that there are cases in which branching is not appropriate, but we talked about very specific cases (spikes, proof of concept, large refactorings …)
The next point that emerges alone is as a team can work on the same branch.
Most of the time, is not that the team wants to work with branches, is that either do not know how, or the current state of development, it is not feasible to work with a single branch.
Get to the point … to work with a single branch, it is essential that:
Team culture, communication and consensus.
TDD, TDD and TDD (Test Driven Development) or at least test, one test is better than none.
Frequent commits. (Program intent. Upload micro-features)
Self, no matter ant , maven , graddle , gulp , rake , grunt , npm , composer , sbt , MSBuild , a script for bash or whatever you prefer … what matters is that I downloaded the code and running a genre script component that works . Try searching the most versatile constructor according to your needs
Having controlled units. The self is often also caters to lower the dependencies of the application. These dependencies should be centralized in a corporate repository as nexus , chocolatey , npm or you prefer
Having clear procedures and automated systems (deploy, rollback, deploy to prod …)
As a conclusion to the subject of the branches, say …
Often the proliferation of branches is due more to the fact that they do not meet the minimum requirements necessary to work with a single branch. So the fact choose to work with many branches is given by this situation, not because it is the most productive.
Once the above conditions are met, the complexity of putting Jenkins , Cruise Control or TeamCity is negligible and comes over to mount setup. I tell you to mount a Jenkins takes less than half a day.
… And in other words … when Jenkins mount it takes more than a day, it is definite sign that the duties are not made.
Before installing Jenkins, make sure your tests are good that autoconstruyes the project and have no dependency issues.
Once mounted and everything works … you will ask yourself is:
