Invotra is an ever-evolving product. Our Product team has a roadmap full of exciting ideas and projects to enhance or rework the Invotra functionality so that it adapts to the changing reality of modern workplaces, and grows ever more useful to new and existing customers alike.
In order to bring these ideas to reality, we need a robust process allowing us to develop and release those changes to our customers in a controlled and reliable manner.
The Invotra release cycle
Invotra releases new features, updates and fixes every 2 weeks to all its customers.
An Invotra ‘BAU’ (business-as-usual) release first takes shape in the minds of the Product team.
Six and a half weeks before the targeted live date, all delivery teams meet in a sprint planning meeting, at the end of which we have agreed on the list of tasks that we are scheduling to add to that specific release.
Representatives of all delivery teams involved in making this release happen take part in the sprint planning, from Product and Architecture to Development, DevOps and QA.
When we have a full specification and a corresponding estimate for the work required, we proceed to do the development and testing.
Once all of the tasks have been done, and the release assembled, we deploy and test it on environments mimicking our customers’ environments, before making it live for all customers.
Occasionally, we need to upgrade our customers’ environments outside of the standard release process. We then prepare an expedited release, which is a shorter version of the standard release cycle (going through the same stages but in a shortened time frame).
Expedited releases are generally reduced in scope to a very small number of tasks, and have to obey a set of criteria which justifies why those changes can’t wait for the next BAU release. Typically, they will contain things like security updates or fixes to highly critical customer issues.
Our teams are able to accelerate the process to respond with the appropriate urgency in such situations while maintaining high quality and reliability. Earlier this year, we delivered an expedited release within a few hours, from start to deployment to live, to all customers.
Ensuring release quality
Each task that is being delivered into one of our releases goes through a thorough testing process, ensuring that it works as intended and hasn’t introduced any regressions.
Each developer tests his own work before the task passes to the QA team for further testing. As part of QA testing, each task is tested in 4 different environments (a combination of internal and customer environments).
To complement our manual testing, we also make use of test automation, as our QA Lead Ben describes in his latest blog.
Let’s get more specific… How do we make sure we release the right thing in the right place?
As the full release cycle takes 6.5 weeks but we release every 2 weeks, this means that at all times we have 3 to 4 releases in progress with our teams at various stages of the delivery process.
So, we need to have solid processes in place to ensure that tasks are worked on and deployed to the correct place and that we know exactly what has been released where and when.
To handle our task management, we harness the functionality of Jira as the place where we define all the work that we are planning/executing. Each functional change is defined in a separate task. Tasks are grouped into sprints and managed via a combination of labels and statuses governed by Jira workflows.
Additional custom fields help us group tasks per components and gather test results.
This allows us to know exactly which team (and who within the team) is currently working on a change, and, coupled with our release schedule, allows us to know which environment(s) this task is currently present on. It also helps us gather metrics on a given release.
I believe there is no reliable release process without effective source code management.
Each block of the Invotra source code is stored in a separate GitHub repository. Within each repository, we have a branch for each release in progress. We use topic branches (feature branches) from the corresponding release branch for all our development, and changes go through a rigorous process before they are allowed to be merged into the release branch.
For each deployment to preproduction/live, git tags are created for all repositories that have been changed as part of that particular release.
How have our releases evolved in the past few years?
When I joined Invotra just over 3 years ago, an ‘Invotra release’ consisted of a collection of changes to our Drupal code. Changes to our environments were managed separately, often in their own agreed change windows. Over the years, the make-up of an Invotra release has changed.
While changes to our Drupal code are still a big part of what we do, we now have a NodeJS API which we improve and make changes to as part of most releases, as well as other codebases which are used in the Invotra product. We also routinely have changes to our environments as part of our releases.
Invotra releases and the release process have changed a fair bit over the last few years, and are continually reviewed and improved to help us deliver better to our customers. If you would like to learn more about the Invotra release process, or what Invotra can do for your organisation, click here to talk to one of our experts.
