This article describes our way of CI/CD adoption giving a closer look on various tools and process changes that helped us being more successful. Development approaches constantly change: not so long ago there was perhaps a single development approach: Waterflow, this was followed by Agile and today it’s definitely DevOps.
Today, DevOps is a way how modern developers create their products.
New methods of continuous integrity, continuous delivery (CI/CD) and continuous deployment came with DevOps growth. Conventional methods of software development and delivery became almost useless because the frequency of new products and versions deployment is ever increasing.
Before the DevOps, most companies delivered software in the period of 1, 3, 6 or even 12 months (also known as Agile days). In DevOps era, weekly, daily, even several daily deployments are standard. DevOps can easily update applications on go without forcing clients to download new versions or use patches.
When CI/CD functions correctly, you don’t even notice there’s been an update.
Development teams adapted to shorter delivery cycles by including automation to their distribution channels. Most teams have automated processes for controlling code and deployment. These changes led to CI/CD and were connected with focus on testing process automation.
Continuous integration (CI) focuses on linking work results of individual developers into repository. This can be done several times a day while the main goal is to detect integration errors in advance and enable wider consistence and development cooperation.
The goal of continuous delivery (CD) is to minimize trouble waters present when deploying of launching. Team implementation usually includes automation of each steps to production release, so that new version release of a product can happen at any time.
Continuous deployment is a higher level of automation in which building/ deployment happens automatically every time there is a code change.
Each of these phases is a part of deployment(development) process.
During constant integration, developers often integrate their code to the main branch of their common repository. Instead of developing individual features in isolation and merging them at the end of the cycle, a developer is able to contribute with new software products into repository even several times a day.
The main idea of CI is to decrease costs of integration by having developers doing this more often than they used to. In practise, developers find conflicts between new and existing code during integration. If this happens sooner, it is expected that solving these conflicts will be easier and cheaper.
Of course, CI is not cure for everything as this process change does not guarantee and further quality assurance. Many developers found out that this integration can prove more demanding in terms of time because they depend on manual procedures to ensure new code does not corrupt existing code or introduces bugs. To minimize troubled waters during integration, CI depends on testing suits and automatic execution. It is important to realize that automation testing is completely different from the continuous one.
The aim of CI is improve integration into an easy and easily repeatable everyday task which lowers costs of development and finds errors at the beginning or during the cycle. The success of CI depends on development team culture, mainly when there is frequent building, and to be concerned with the errors(bugs) immediately when they appear. If it is inevitable, changes in team have to be made so that CI process is sustainable.
Continuous delivery represents an extension to CI in which software delivery process is automated to enable easy and reliable deployment to production anytime.
Mature CD processes produce code that can be deployed immediately. With CD, release of a new software version becomes a routine without stress. Development team is able to continue with everyday work knowing that they can build production version ready for releasing without any delays or further testing.
CD depends on central release process in which the team automates processes of testing and releasing. This process is an automated system that triggers progressive set of testing suits after builds. CD is highly automated and easily configurable.
In each segment of the process each build can fail at critical testing, in which case the team is notified immediately. In other case build continues with further testing which leads to automated start of next process. The last segment of the process deploys the build into semi production environment. This represents a complex activity because building and deploying into semi production environment are executed and tested together.
The result is a build that is safe to deploy and runnable in real production environment.
CD is considered attractive mainly because it automates all steps from saving code to repository releasing fully tested functioning blocks that are ready for production. CD is a sophisticated automation of building and testing processes but also deciding what, when and how to deploy. Continuous deployment can save precious time that there is ever so little.
Continuous Deployment extends CD so that software can be automatically deployed and if it passes all tests. In such a process, it is necessary for a person to decide what and when goes to production. The last step in the CI/CD system is Continuous Deployment which ensures automatic deployment of all components/ packages that successfully finishes delivery of the whole software. Continuous Deployment can be configured in a way that new features, changes and bug fixes are quickly distributed to clients and provide overview of what was put into production.
The biggest benefit of Continuous Deployment is that users are able to respond to new version quickly.
A quick response on useless or misunderstood functionality helps the team to focus on improving or completing functionality. Due to the fact the new versions are delivered in a quick fashion, any errors spotted should be dealt with immediately. In other case there is a risk of overloading the team that has to deal with both — deliver new functionality and fix bugs at the same time.
For planning and tasks control Redmine with various plugins is used. Swagger and Swagger generator are used for smoother API implementation. For administration of repositories, GitLab comes handy which enables integration with Slack and Jenkins. For building, automated testing and deployment on production we use Jenkins, JMeter and Katalon. The production itself is secured by Docker containers.
Martin Kapinos, Software Architect at localhost.company
We would like to introduce you to our new interview format, which will be gradually added to our blog. As the first in line, we interviewed our Croatian colleague Mario Plantosar, who is a react native developer. He told us what he does in his free time, how he hacked a computer at his elementary school, and when is the best time to visit Zagreb.
Welcome to this interview where we dive into the world of product owners in the software development industry with our colleague Karol. According to him, being a product owner is an exciting and dynamic role that includes a wide range of responsibilities. We will find out what he learned in the Romanian city Cluj and also, what vacation destination he recommends. So, let’s get into it and explore what it’s like to be a product owner in this rapidly changing and innovative field! :)
Data science has become a powerful field that combines statistical analysis, machine learning, and domain knowledge to extract valuable insights from complex datasets. By leveraging data collection, cleaning, exploration, modeling, and visualization techniques, businesses can uncover patterns and correlations that drive innovation and decision-making. Let’s explore the exciting world of data science and its transformative impact across various industries.
Some people bike or watch series in their free time. Our colleague Michal Géci, however, used that time to create his own arcade game called Ulrich. It’s about a vampire who one day receives a strange letter. After long nights of story development, drawing, programming, and composing music, he revealed more to us :)
Our client is one of the biggest suppliers of spare parts for transport vehicles and buses in Slovakia and the only producer of buses in our country. With more than 90k different kinds of commodities in its warehouses and growing operations every year, the point where all the stock movements in, between and out of the warehouses became particularly challenging was reached. It has had certain implications for controlling, reporting processes and in overall transparency of financial and data flows in company.
Need Code Expertise?
Contact us
