Practical advantages and pitfalls of introducing continuous integration (CI) into (not only) a web integrator environment, what is easy and what is harder, what requires attention, whether we speak about tools or people.

Also, you should not miss the previous part of the article series about web integration – Front-End Task Automation – Part 2. It is a must-read!

In the current era of strong competition and high pressure on maintaining output quality, one of the essential parts of effective development and web applications is continuous integration (CI). Implementing of a correct and compact CI process is not a matter of one day and may contain obstacles. The last but not least aspect of the process is the actual speed of change distribution into various environments, where continuous integration greatly helps reducing errors while reaching a sufficient speed.

Required tools

The subject of this article is not a detailed analysis from a technical perspective. To give you a better idea, I recommend the previous articles, Advantages of continuous integration and automated deployment from the perspective of web integration and Version control system and web integration projects.

For a general idea, let us at least provide a basic list of tools and information systems that need to be integrated into the production process of a company:

• Version control system, preferably distributed (Git, Mercurial),
• single source code repository (Github, Bitbucket, Bonobo Git Server),
• package and code dependency management system (Apache Maven, Ruby Gems, NPM, Composer),
• continuous integration management tool (Jenkins CI, JetBrains TeamCity, Atlassian Bamboo, Team Foundation Server [TFS]),
• automated testing framework (unit testy [PHPUnit or Junit Framework], Selenium).

Pros and cons

Implementing new systems means changes in both the infrastructure and the process level and affects operation principles of the whole company. Individual workers’ reactions to those changes within an organization will vary. Generally, significant changes do not cause waves of enthusiasm throughout the whole organization. A part of the staff will believe the existing system is sufficient and will prefer using the established procedures.

Another part will be indecisive and will wait until those changes are proven and have acceptable consequences. Those people will neither vote against changes nor actively support them. Finally, the third part of the workforce, dissatisfied with the current state, will more or less support the changes. The last-mentioned group may also contain future members of a team responsible for the correct setting for the new systems and maintenance.

Apart from the technical support itself, the last group also has a significant psychological impact on their co-workers, which they can naturally convince of the benefits of changes in work procedures. Enthusiastic supporters will gladly learn the new system and will naturally pass the enthusiasm on their co-workers.

Therefore, the changes will not seem as “dictated from above” and will be regarded as actually beneficial.

Do not get me wrong, however. The group of critics is not trying to prevent progress, it only requires us to clearly describe what benefits the change would bring them at the price of their temporary discomfort.

The most common objections against changes that consist of implementing an infrastructure and a continuous integration process:

1. Learning to use new tools requires extra time.
2. New tools are lacking functions of the old tools.
3. New changes cause confusion in the established procedures and lead to errors.
4. It comes with additional standards and limitations.
5. Automation reduces the developer’s control over the deployment process and the control of a code deployed into a runtime environment.

Counter-arguments:

1. Workers increase their qualification and broaden their knowledge.
2. Modern systems supporting continuous integration feature most of the previously used systems’ functions, and also:
   • Include additions/extensions that can partially or entirely replace functions of the old system.
   • Allow integration into other systems within the continuous integration process.
   • Allow integration into bug & issue tracking systems.
   • Feature new functions that can be used to improve work effectiveness.
3. Short-term decrease of effectiveness is compensated by a long-term increased level of stability and a better-quality (more easily estimable) output towards the clients.
4. In a clearly specified system, standards also serve the workers as manuals that always define a repeatable process; bigger changes allow more substantial reworks of the established security models, improving them qualitatively.
5. Replacing manual work with an automated tool reduces the probability of human error and limits responsibility to a smaller group of people. This also means the developers, after submitting their work, do not have to worry about if and where their work has been deployed.

Where to look for good advice and a helping hand?

Implementing new systems and their setting for the company’s specifics requires a considerable time. Some attempts may end in failure, or a certain direction may prove to be a dead end. In any case, it will provide us with valuable experience, even though it costs us valuable resources. Implementing a compact system may take hundreds of hours of work. Good information can save a significant portion of the worker’s time required to acquire new skills and, last but not least, spare our nervous system.

Available source of information:

• Internet – on the internet, you can find documentation, manuals, personal experience of individuals and discussion on a given topic.
• Customer support and community – you can consult the customer support (in case of commercial products) or the developer community (in case of open source).
• Seminars, training – as in any other field, you can attend to seminars or training.
• Consultant – a subject with experience.

The aforementioned options are more or less sorted according to their cost and also reflect the quality of received support. Both open source and commercial systems usually have out-of-the-box functionality preset to the most common user requirements. In most cases, you can thus start working almost immediately. A lot of information is free of charge as long as you are able to find it. Time, however, is not free, and hours of experimenting on your own can be avoided by an individual consultation.

To make the transition as painless as possible, it might be worth it to involve an external consultant specialized in continuous integration or to cooperate with a company in your field that has already implemented such system and uses it successfully. A subject that experienced a transition from an uncontrolled system to continuous integration can provide you with:

• Personal experience that can point you in the right direction.
• Warning against a number of errors resulting from experimenting with new tools and processes.
• Help with a basic setting, which you would otherwise have to discover on your own.
• Recommendations on how to adjust the basic setting to the needs of your organization.

Besides that, it will act as a mentor and role model for your employees, a presence of such person usually makes the team more inclined towards changes.

Implement changes gradually

It is not wise technically or organizationally to turn all systems upside down. For instance, the maintenance of ongoing projects requires the impact to be as small as possible. In this case, we recommend to fine-tune the process on a chosen project and then apply the process on other projects.

Our suitable candidate should not be too small and should generate sufficient amount of change requirements, on which we can test the process and learn it. Besides, this way the participants will be shocked to a lesser degree than they would be otherwise. Despite all efforts for a smooth progress and maximum efficiency, not everything will be perfect since not all risks can be prevented. Unexpected events throughout the development process require a certain level of improvisation and inspiration.

But if you anticipate these risks – especially if you involve an expert consultant – you will overcome the period of implementing changes smoothly and to the satisfaction of developers, managers and clients. In the second part of this article, we will focus on practical experience with implementing of some of the aforementioned tools and information systems in the building process of continuous integration in a web integrator environment.

You can now follow to the next part – article called: Putting Continuous Integration (CI) into Practice – Part 2.