The benefits of the DevOps culture in the creation of digital products are no longer discussed. If you are not interested, you will have your reasons and we respect that. If instead you are interested in ensuring these benefits, Continuous Integration (CI) is an omnipresent practice.
Competitiveness at digital speed
as proclaimed Manuel Recena, continuous integration is a difficult Software Engineering practice, but one that offers us a great reward.
Continuous integration is essential for the creation and launch of digital products in competitive markets, which require us to adapt quickly.
That's the big “for business” payoff, but the people involved also benefit from the boost in collaboration, automation, and short evaluation cycles. Everybody wins.
Alternatives to not fail
The wealth of alternatives to implement continuous integration is a universe in permanent expansion. Finding the right flavor is one of its many challenges. To the options at home (“on premise”) we have to add the options in the cloud, which are extremely attractive: Azure DevOps, Google Cloud, AWS Devops and so on endless more. In many of our articles you can brujule about it... But before we get excited about these dazzling options, we propose to recover the bases, the fundamentals for feed our conviction.
The basics of continuous integration
In this sense, we recover some of the mantras of the remarkable talk organized back in 2014, by the DevOps group from Madrid about continuous integration. Ingredients: great rapporteur (Manuel Recena), good framework and assistance, and intense third half. Manuel and Antonio Manuel Muniz (his partner at the time) conspired to "not talk about his book" and complied. Many of the pearls that they gave us, cultivated after years of experiences, clients and reflections, are still valid today. Sincerity in vein.
1. Fundamentals from a purely technical point of view…
What technological alternatives do we have? The number of options continues to grow remarkably. Manufacturers are releasing suites and you even have to choose, as we said before, between “on premise” (locally) or in the cloud. Y the choice is not trivial.
How do they integrate with the tools we have? It must be kept in mind since it conditions the real options. Also consider support for multiple technology stacks, since continuous integration is a general-purpose system, and support for different build tools.
If you do not already have a construction tool in use, that is, an already modeled process, you have to solve this aspect first.
And what happens if the number of users and projects increases? If the chosen solution is linked to the number of users/projects, the cost can skyrocket. And how will the maintenance be? It is very dangerous to scale an experimental initiative, because we can find the effect "the one who set it up left".
2. The human factor appears on the scene…
- From people with a lack of perspective:
- "We assembled that in a week."
- "Continuous Integration is to mount a Jenkins and that's it".
- "That's the Jenkins fault, it works on my computer."
- Until serious evolutionary problems:
- Teams where there is no room for fresh ideas and there is reluctance to change.
- Continuous improvement is a term they only use when talking to their child's tutor.
- "Interesting, but now we don't have time." There is never time.
- "If it works, don't touch it"... taken to the extreme.
- "We work for a client and the NDA prevents …".
- In each project they solve your needs.
- Going through ill-conceived ideas:
- Automating is not doing continuous integration.
- Continuous integration is a means, not an end.
- The tools help, but the important thing is the processes.
Anyway, as we are human beings, let's air the information. take care of them information radiators compensate because:
- To give value, you have to measure.
- We avoid having scattered and disorganized information.
- We use explicit notification systems: mail, messaging, chat, twitter, iRC, …
Continuous integration seeks to control the relationship Cause -> Effect -> Radiate. I segment the steps and automate them in order to control the effect. Thus, when faced with changes in the effect (“something has gone wrong”) I can focus on looking for the causes within that segment.
3. The decision process that awaits us…
First crossroads on the road
Do we mount it or use product?
A maxim. If it's not your business, stay out. If doing it yourself, you are not able to justify a positive ROI, do not do it. The cost exists. It is not in the installation and configuration, but in the maintenance and integrations. Also consider access control, unique if possible.
At home or as a service?
Do you have infrastructure and people with experience managing (sysadmin) this type of tool?
Does the cloud still scare you?
Do you have contractual restrictions imposed?
About construction tools
They are a key piece. Basic requirement.
It is the language that our Continuous Integration server will understand.
There is a very important relationship between the build tool (Maven) and the CI server (Jenkins). There is something for everyone, the important thing is that you can reach the same goals.
Finally, it is worth mentioning a set of Good practices, which are the result of effort, attention to detail and maturity in Continuous Integration.
It's advisable respect a structure for easy navigation between projects, and also brings maturity. The proposed automation lines are:
- Compilation, packaging and distribution.
- activities until son my artifact.
- Distribution is the task that grabs the artifact and uploads it to the library (let's say Nexus).
- Documentation generation.
- We explain in this article the magic of ongoing documentation in two pills.
- A very large fan opens, from unit tests to performance tests.
- Code inspection.
- Cybersecurity… “call me DevSecOps!”
- Deploy or pass the result to some environment (pre, test), not just production.
And now some very wise advice to ensure productivity:
- Create tasks for each «cause» that you want to control.
- Define naming conventions.
- Define an execution policy. This policy determines the cost that the use of the ecosystem will entail. For example:
- Code inspection at night.
- Pack with each commit.
- Use mailing lists for notifications.
- Team members then subscribe to mailing lists that interest them.
- Apply early definition.
- Define the minimum tasks that you want to have in all projects and thus, when the project grows, you already have the task base assembled.
And as a closing, we rescue these 4 pearls:
- There are many aspects that influence the corporate implementation of this practice.
- Continuous integration tools must be completed with notification tools.
- Do we have all the weight of the construction process in the development tool (IDE)? There are people who are trapped by the IDE, such as iOS or microcontrollers. They have a hard time knowing how to build their software without an IDE.
- How to convince a dinosaur? It is very difficult. Perhaps making you reflect on the efforts or problems involved in moving things to production.
In short, Continuous Integration (CI) is a DevSecOps practice to control the Cause -> Effect -> Radiate information relationship when building software products. Segment and automate to be able to control the effect, detect changes quickly and react quickly. And so, the Time to Market accelerates. At Panel we know that applying Continuous Integration is a demanding process that requires a particular software construction culture, so if you are interested in learning about our interpretation and implementation of the issues raised here, go ahead and discover a new perspective on creating software.