Deliver and communicate faster thanks to git and GitHub
As a Decathlon engineer of a 100,000-employee sport company embracing micro-services, being great at communicating has become a condition of survival.
Joining this need with the fact we are changing our business and the time to market is leading all our new projects, is making us think how to automate this communication taking the advance from the developer tools we are using.
Let me show how we decided to do our first step.
Continuous Delivery vs Continuous Deployment
The base for both two is that you want to deliver faster. But there are some small differences in them. You can read an old post from the Puppet Blog which is explaining this better than I can do.
Continuous Delivery is a series of practices designed to ensure that code can be rapidly and safely deployed to production by delivering every change to a production-like environment and ensuring business applications and services function as expected through rigorous automated testing. Since every change is delivered to a staging environment using complete automation, you can have confidence the application can be deployed to production with a push of a button when the business is ready.
Continuous deployment is the next step of continuous delivery: Every change that passes the automated tests is deployed to production automatically. Continuous deployment should be the goal of most companies that are not constrained by regulatory or other requirements.
You have to choose! And not only based on your business but also from your technical infrastructure. If the production deployment is causing service disruption, deploying several times a day or in an unpredictable moment will create a problem at the business level.
What about the versioning in this automatic system?
How you can decide to move your code from v. 1.0 to 1.1 or to 2.0?
There are several ways to define the version, even directly in your code source, but in my case, I thought that could be difficult to manage in a team where several developers are working at the same time on different new functions. Who is deciding the version? How you can manage the version conflicts merging the code?
To simplify this part we decided to delegate the versioning to our Continuous Integration System. We even have a separation between the version we want to communicate to our customers (readable and easy to “spell”) and the one we use technically on our system (where we want to prevent some unwanted chars).
We told ourselves what to do for a great workflow:
- Create a customer product version based on a simple date. We are just adding a number at the end, to be able to deliver more than one version per day: 19.01.13–0
- Set a technical product version based on the branch name which is built. If the CI system if building a PullRequest the name is containing the information to identify it: SNAPSHOT-PR-141- 33f8bf0–20190113231200
If you are building on the master branch, the Pull Requests only contains information from GIT and from the build date/time: 33f8bf0–20190113232523.
The version is defined by the CI system, so the date/time can’t be the same to the one of the original PR.
How we are doing it with Jenkins?
We are using this simple library which is doing what I described before:
- the getNewVersion function creates the customer version.
- the getBuildImageVersion function creates the technical one.
Releases
A product release is the process of launching a new product for a specific market or user base. In software development, a product release is sometimes done with a beta version so that core developers/users can assist with debugging and feedback prior to the release of the actual software.
(from Techopedia)
In Continuous Deployment workflow, a release is always (or most of the time) containing a single function/bugfix/…; In Continous Delivery, the pre-release, deployed into the integration environment, is always a single function, but the one deployed in production can contain several compared to the previous one.
In our case, we are pushing a tag into the customer style version on git and we are then creating a pre-release on this tag… always through our CI system.
Create Changelog
We are creating a changelog text using the following function:
Which is then used by our main Jenkins file to create the release via the GitHub API.
You can see the final result directly on GitHub that should look like
Release Notes
In a Continuous Delivery workflow, how to communicate a concrete changelog to your users? Yeah I know, the easy way is to write it manually somewhere, but try to imagine you don’t like to write it manually?! :-)
Looking around on the net, especially on some major open source project, we decided to replicate what Spring is doing on its products… and we have even found how it is doing it. I really love open source! :-)
As we are manually deploying when we need it, we are sometimes pushing to production once a day, and some other times only once a week or less. We thought that a massive communication, even if it mostly automatically does, can be boring for our users.
Do they really want to have information each time we are pushing in production?
On this part, we decided to communicate only once a month (about 1 sprint) giving all the information about the things done between the version used in the previous communication and the latest deployed in production.
To simplify the job we are grouping into GitHub Milestone all the PR and Issues we want to communicate about (normally should be anything… but you know, sometimes we have really useless stuff :P).
You have to use some base tags like bug and enhancement to be able to class your issues in your release notes communication.
When you are ready to communicate you can simply run the SpringIO script and get your beautiful result in an MD format.
Then you can communicate it as you prefer, yes I didn’t remember this part: it is a manual communication…. but it is the only one and you can delegate this part to your Product Owner.
We decided to fully use GitHub and communicate our release notes on a Wiki Page.
Improve the readability
To automate your communication you have to work with strong bases: if your commit messages pull requests or issue titles are not self-explanatory, the release note you are producing can’t be understood by your users.
In this way, I think you know you are communicating a thing that nobody can understand. So, why do you want to share it?
To help us improve our pull request messages, we decided to introduce the Semantic Pull Request plugin on our projects: it is blocking us on merging a pull request if the title is not respecting the semantic rules.
As it is reported on the documentation, you can use any of the conventional commit types to identify your pull request: feat, fix, doc, style, refactor, perf, test, …
But the plugin is not doing all the work: all your titles and messages must be as much clear as possible. The result in not doing it is that you have to manually communicate the list of feature and bugfix you have in your releases.
You can, for example, read the release note from Spring or Spring-Boot, even if it is a really technical release notes, it is clear what are the functions or fix you are installing with the new version.
Conclusions
- If we change our development workflow and we want to be more reactive than in the past, we also have to change all the project management level and communication.
- In my opinion, the target should be the full automation of your process, or at least automate it as much as possible. Keep manual operations probably means you are not doing it every time leaving some part of your projects or some tasks outdated.
- We can recover from git all the information related to commits, tags, developers names,
- Taking the advance from GitHub API, we can automatically publish a new version release and notify the subscribed users.
This process simplifies a lot our everyday work but is maybe not the best one we could use. What about yours? Do you have any better thing to share or best practice you are applying to your projects?
Subscribe to our newsletter on http://developers.decathlon.com
Love sports and tech? Us too! Join us on our career website https://developers.decathlon.com/careers
