COMPANY BLOG

Continuous Integration (CI) in Practice – #1

12.11.2020

The practical benefits and drawbacks of incorporating continuous integration (CI) into (not just) a web integrator context, what is easy and what is difficult, what demands attention, whether we are talking about tools or people.

Continuous integration is an essential component of the efficient development of online applications in today’s era of intense competition and great pressure constantly maintain output quality (CI). Implementing a good and compact CI process takes time and may end up facing challenges. Last but not least aspect is the real speed of change distribution into diverse environments, where continuous integration significantly helps in decreasing mistakes while obtaining the necessary speed.

ESSENTIAL TOOLS

Let us start by giving a broad overview of the tools and information systems that must be integrated into a company’s production process:

  1. Single source code repository (Bitbucket, Bonobo Git Server, GitHub)
  2. Continuous integration management tool (Team Foundation Server [TFS], JetBrains TeamCity, Atlassian Bamboo, Jenkins CI)
  3. Automated testing framework (Selenium, unit testy [PHPUnit or Junit Framework])
  4. Package and code dependency management system (Composer, Apache Maven, Ruby Gems, NPM,)
  5. Version control system (Mercurial, Git).

ADVANTAGES AND DISADVANTAGES

New system implementation necessitates adjustments at the infrastructure and process levels, which has an impact on the whole business’s operating principles. Different employees will respond differently to these changes inside a business. In general, big changes do not send shockwaves of enthusiasm across the whole company. A portion of the staff will favour using the established procedures and think the current system is appropriate.

While waiting for such adjustments to be established and to have acceptable results, another part will remain hesitant. These individuals will not actively support or oppose reforms. Finally, the third segment of the workforce, which is unhappy with the situation as it is, will mostly approve the reforms. Future team members who will be in charge of putting up new systems correctly and performing maintenance might be included in the last category stated.

In addition to the technical support itself, the final group also significantly affects their co-workers psychologically, whom they may naturally persuade of the advantages of changes in work methods. Supporters who are enthusiastic about the new system will happily learn it and naturally spread that excitement to their co-workers.

As a result, the adjustments will not look to be “dictated from above” and will instead be seen as positive.

Do not misunderstand me, though. The group of critics is not attempting to hinder change; all they want is that us to make it obvious to them what advantages the change would bring them in exchange for a little period of discomfort.

The following are the most frequent arguments against changes that involve the establishment of an infrastructure and a continuous integration process:

  1. Automation limits a developer’s ability to manage the deployment procedure and the code that is put into a runtime environment.
  2. It takes time to learn how to use new tools.
  3. New modifications produce confusion and mistakes in existing practices.
  4. The functions of the previous tools are missing in the new system.
  5. It has extra requirements and restrictions.

Counterarguments include the following:

  1. The knowledge and qualifications of the employees grow.
  2. A short-term drop in efficiency is offset by a long-term improvement in stability and a higher-quality (more easily estimable) output to clients.
  3. The use of automated technology to replace manual work decreases the possibility of human mistakes and limits responsibility to a smaller number of individuals. This also implies that developers do not have to worry about whether or not their work has been deployed after submitting it.
  4. Standards also function as guides for employees in a well-established system, creating a repeatable procedure; larger modifications allow for more comprehensive reworks of the existing security models, improving them qualitatively.
  5. Most of the functionality of earlier systems is still present in modern systems enabling continuous integration, and additionally:
  • Include innovative technologies that may be utilized to increase productivity.
  • Allow integration with other systems within the process of continuous integration.
  • Integrate with bug and issue-tracking systems.
  • Include additions/extensions that can partially or completely replace outdated system functions.

WHERE CAN I FIND GOOD ADVICE AND A HELPING HAND?

Implementing new systems and customizing them to the needs of the company takes time. Some attempts may fail, or a particular path may prove to be a dead end. In any event, it will provide us with significant experience while costing us vital resources. Building such a compact system can require hundreds of hours of work. Good knowledge may save a substantial amount of time necessary for workers to learn new abilities and, last but not least, it can save our nervous system.

Possible sources of information:

  • Customer support and community. In the case of commercial goods, you can contact customer service or the developer community (in the case of open source).
  • Internet. Documentation, manuals, personal experiences of individuals, and discussions on a certain issue can all be found on the Internet.
  • Consultant. Use the help of an expert in the field.
  • Seminars, training. You can go to training sessions or seminars, just like in any other field.

The abovementioned alternatives are organized according to price and also signify the kind of service received. Both open-source and for-profit systems often come with pre-configured functionality that meets the majority of user needs. Thus, you may often get to work almost immediately. If you can identify it, you can find a lot of knowledge for no cost. But time is not cheap, and a private consultation might save you from spending hours on your research.

To make the transition as pleasant as possible, it could be beneficial to collaborate with a company in your industry that has previously successfully implemented such a system or to seek the assistance of an external continuous integration consultant. You can learn the following from a subject who underwent the changeover from an uncontrolled system to continuous integration:

  1. Recommendations on how to modify the default configuration to suit your organization’s requirements.
  2. A variety of mistakes that might happen when using new tools and procedures.
  3. Help with a fundamental setting that you otherwise would have to figure out on your own.
  4. Personal experience might lead you on the proper path.

Furthermore, it will serve as a mentor and role model for your employees; the presence of such a person typically makes the team more open to change.

IMPLEMENT CHANGES GRADUALLY

Turning all systems upside down is not a smart organizational or technological decision. For instance, the impact must be as little as possible to maintain current projects. In this situation, we advise fine-tuning the process on a particular project before using it on others.

Our ideal candidate should not be too small and should have enough required changes for us to test and understand the process. Additionally, the participants will experience less shock with this approach than they would otherwise. Despite every attempt to ensure efficiency and smooth progress, not everything will go perfectly since not all risks can be eliminated. Unexpected situations that arise during the development process calls for some creativity and improvisation.

However, if you foresee these risks and, in particular, engage the assistance of a competent consultant, you will be able to manage the period of implementing changes smoothly and to the satisfaction of clients, managers, and developers. In the second part of this article, we will concentrate on our practical experience using some of the information systems and technologies discussed above to construct continuous integration in a web integrator context.

You may now go to the next section – an article titled: Continuous Integration (CI) in Practice – #2.

 

Lukáš
Lukáš

Leave a Reply

Your email address will not be published. Required fields are marked *