How to automate Release Notes preparation in a modern development team
Release Notes are an important part of software documentation. With their aid, the team keeps track of the implemented functions, PMs control the development process, sales managers report to the client, and the customer keeps their finger on the pulse of the product. Thus, the crucial point in Release Notes is relevance of the information, and the document itself must be easy to comprehend. We're sharing our experience on how we collect release reports — quickly, properly, and without any manual labor.
We started Release Notes automation several years ago. Our aim was to bring them to a single standard for all teams; to save team leads and PMs from manual material preparation; and to insure against potential errors that certainly arise when something is done manually.
On our internal portal, we created a web constructor which enables the assembly of a ready-made release report with a few clicks. The service is integrated with task trackers, from which it automatically downloads all the release data. On return, the app generates a formatted email report for the client. All information is split into categories; each paragraph has a link to the corresponding tracker page.
Why the changes were needed
For a few years, the tool performed well in this form, but progress never stops. When we started to adopt Trunk Based Development (TBD), the approach to Release Notes had to be changed as well.
The TBD concept assumes that development is ceaseless, and the team is constantly publishing updates in micro-releases. This accelerates the product development, shortens the Time-to-Market (time from the development start to the product delivery to users), and provides developers with swift feedback from the client and users.
Another factor is that, in recent years, most of our products have moved to microservices. This architecture implies that the teams use multiple repositories for each microservice involved. Release of one feature includes several releases for various microservices, and tracking them is quite difficult.
New mechanics
We have re-examined the Release Notes preparation, relying on the automatic PBI analysis (Product Backlog Item, for our purpose — a whole task in TFS terminology). Before that, we had already set up automatic task tagging so that QA engineers could see which features may be taken for testing. Now these very tags are used for Release Notes.
The scheme works on the basis of TFS Aggregator — this service enables automating many manual operations when working with PBI. For example, it can track when the PBI's last task receives the “Done” status, and mark the entire PBI as complete. Moreover, the Aggregator can work with the rule base very flexibly — divide them by projects, by task types, etc. In general, it takes ideal care of routine work which otherwise consumes lots of the team's time and effort.
We wrote a plugin for Aggregator that scans the PBI daily and tags tasks sent to the prod-environment. Then a special Camunda process uses the tags to collect data for the letter to be sent to the managers, directors, and the sales department. This information proceeds to our Notification Center, which packs everything into a neat letter made up according to a given template. The Notification Center also enables setting up a convenient mailing mode for different user groups — once a day, a week, etc. In the near future, such fine tuning will also appear in our Release Notes service.
That's what the automatic Release Notes preparation currently looks like. The solution pilot has already started on two of our projects, and soon the new mechanics will be expanded to all other teams.
Its charm is that it will be very easy to scale this experience — one just needs to email the technical support a tag that the Aggregator should catch, and a list of addresses where the Release Notes are to be sent.