Release IT anytime
We all have seen that 2020 has introduced many changes around the world. The first reaction to the change needs as fast as possible. As for government and for enterprise and smaller companies, changes required to be evaluated and executed (released) within days or hours, or even minutes. Software development isn’t an exception.
Within this series of articles, we would like to share with you our experience and solutions we found handy to achieve a sustainable change cycle.
We tried to split it into 4 primary blocks application process:
2. Continuous integration
3. Continuous deployment
The first series will be described from the bird-eye view these blocks and in upcoming articles, we will introduce a detailed overview of every block.
We all know applications begin with the so called “Hello world”, which is the first very draft version of the application for the first commit into the code repository. Since that first line of code for the application every team is responsible for his own beautiful Ken or Frankenstein creation. Ok, I am kidding, of course beautiful Ken, it is 100% like that and no doubts 😊
As the Team starts proactively developing and making commits into code repositories and more and more changes are needed to be delivered and the product is already in production, many open topics can come, which every team should resolve with the evolution of the application.
1. Git flow, Trunk based development, Feature toggles;
2. TDD, BDD, DDD;
3. Scrum vs Kanban.
Every software new functionality development requires to ship the code to the end-user. Thus needed to combine bundle or artifact (docker image, jar, war, exe, dll, js lib, etc). Continuous integration is the key part of building from source code artifacts. Usually, continuous integration contains multiple steps:
1. Build artifact from source code repository;
2. Automation testing;
3. Release/Publish artifact.
During this series, we will discuss different possible options for automating continuous integration processes using different tools and steps in detail, which are must-have to succeed to release it anytime.
When the artifact is produced the next step is deployment. There are many types of deployment processes adopted by different companies.
1. Manual approval and manual scripts for executing the release;
2. Manual approval and automated tools for deploying artifacts;
3. Fully automatic deployment process without human interaction (afterward notifications).
Our experience states that the proper deployment process is a very important part. If this part is not well defined or setup usually introduces delays and a long time to deliver artifacts and frustrations inside of the team, product owner, and stakeholders. Of course, the worst-case when the wrong version of code is deployed to production. Guess everyone has heard about such an issue at least once 😊
Metrics itself has very abstract and broad definition. Metrics during the development process is the core of all 3 processes: continuous software development, continuous integration, continuous deployment.
Every block has its own metrics and narrow focus. Without these properly defined metrics is not possible to measure success or failure points, which require improvement. Clearly defined metrics are a very important part of constant improvement. As well metrics can be good proof to management to invest time for the team to release it faster.
Correct metrics lead to establishing right monitoring, which will reduce false alerts and have a proper and fast reaction on real problem.
Thanks, everyone 😊 Hope this series will be interesting for you and we will try to share solutions for the problems to “Release IT anytime”. If you have any questions or topics to include in the series feel free to write us directly.
There’s no use talking about the problem unless you talk about the solution.
— Betty Williams