Release management software - OpenProject

We as a software company of course use our own product to plan and manage our releases. OpenProject users know that we are trying to release often to bring incremental added value. So how do we manage our releases and how does OpenProject as release management software work? The following shows you some aspects on how we are planning and implementing.

Planning in the release management software

Basis of the release planning

As usual, basis for our work in OpenProject is the work package table. To manage our releases, we are using different types of work packages: Release, Epic, Phase, Milestone, Task, Feature, Bug, Idea, Implementation, Documentation, Testing, Code Maintenance. This allows us to record everything that needs to be planned and done for a new release. We start from going big to small in the planning process. Add Ideas, make them into Epics, add Features and Milestones, schedule a Release etc. The work package table allows to always add and change work packages as you go along. And all changes and additions will always reflect in all modules in OpenProject.

On the work package table basis, we are saving different views of the work package table, created by filters, to be able to check on certain information quickly.

Feuille de route

We are using two roadmaps for the release management. The first one is one on a high level, it is a Gantt chart view of the work package table, displaying epics and releases. That way the viewer can check on OpenProject’s development focus and for when certain features are scheduled.

Then we are using the actual roadmap module in OpenProject to keep track of what needs to be done for a release and what has already been done. All work packages by release are displayed and give an accurate and up to date status of the development. Closed work packages show as crossed out. The closer you get to a release date, the more details this roadmap will show as the number of work packages increases.

Release plan

The release plan is a timeline for us on when the next releases are planned without any other details. It serves to quickly look up timings for anyone in the team. It is of course integrated in the release management as it is just a Gantt chart view with set filters.

Development and testing in the release management software

From planning which is actually ongoing and ever-adjusting, it goes into development in several iterations.

Feature development, improvements and bug fixes

All work packages go through a defined workflow from specification to development to testing and closed. You can set up your workflows according to your needs.

Whilst working on features, improvements and bug fixes, the team uses the OpenProject-GitHub integration. It allows to match the work packages with pull requests in GitHub so that the latest development is always available. The work package detail view displays the GitHub actions and the corresponding pull request.

Agile board view

Sometimes, the dev ops team also likes to use a board to visualize their tasks. In the example it is a basic board to prioritize work packages.

QA of the release development

Once a work package has changed its status to merged, QA will start. In case a feature tested successfully, the QA team will set the status to closed. If the QA team finds a feature not working according to the acceptance criteria, the work package will be set to test failed and assigned back to the developers. If there are errors not strictly relating to the acceptance criteria, a bug report is opened. We track the work package status by filtering for all open work packages and sorting by status.

On top, we are using a list to prioritize bugs.

Release checklist

To make sure that everything is covered, we use a checklist for every release. It is basically a work package table with milestones that can be ticked off easily. It almost serves as a to do list. This way, we make sure that all testing is done, communication to our users is prepared, all technicalities regarding the deployment are taken care of.

Monitoring and improvements in the release management software

We deploy the latest OpenProject release first on Community after extensive testing. That allows our community to test features first and give valuable feedback and report bugs. Thereafter our Enterprise editions are released: we publish the release for the Enterprise on-premises version and deploy the Enterprise cloud. We offer our Enterprise on-premises customers support to upgrade to the latest release. Careful monitoring and patch releases ensure highest quality of our releases.

Our OpenProject project is available publicly, don’t hesitate to browse a bit more or read up on the release process in our documentation.