Onesait Platform Upgrade Methodology

Owned by DevPortal Editor (Unlicensed)
Last updated: 21/06/23 by Onesait Platform
4 min read

In Onesait Platform team, we follow a methodology to improve the product and eliminate the bugs that can exist.

Issues and branch management

We have a GitLab repository where we have our code and different branches. In Gitlab we have 3 types of issues:

  • BUG: error to fix

  • UPTURN: some improvement in the platform

  • FEATURE: new functionality

Our principal branches are:

  • Master: this branch is the Stable code branch. From this branch, the stable release branches are generated within the quarter.

  • Develop: branch of new features programmed within the Q. This branch merges to master, once stabilized and tested and once the Q is over.

  • Integration Branch: this is our weekly branch where we upload bug fixing and upturns. It merges both to master and to develop. This branch is generated from master.

Every issue is solved in a particular branch and then merged in the proper branch, usually by someone who did not solve the issue in order to assure that at least 2 people have checked the code. Besides, the issue must be associated with the corresponding milestone (weekly if it is a release candidate or RC) or quarterly if it is intended to the Q's end.

Once the issue has been solved, its state is changed to 'DONE'. Then, when it is tested and validated in the proper environment, the issue must be closed.

Version policy

At any moment we have 2 versions: stable version and development version.

A new stable version is generated every Q with a specific name. Weekly we have release candidate versions and monthly we have the next minor version.

The development version has its own route. It is named one number ahead of stable version and it has all fixes of the stable version, improvements identified and new features.

For example, in stable version we can be in 1.5.1-rc3, so in development it will be 1.6.0 version. Next week, stable version will be 1.5.1-rc4, which is the last one of the month, so it becomes 1.5.1-name version.

Test methodology

Every night, Jenkins compiles all the code of the Onesait Platform to check if everything is correct.

Also every week, after closing the release candidate version, it is deployed in our stable environment. For this purpose we use Jenkins, our tool for continuous integration. In this pipeline, it compiles all the code from the branch, generates Docker images for all our modules and deploy them in our environment.

Our images are published in our private image registry, which are then distributed to the different projects/solutions that make use of the Platform.

From this registry and templates of Cattle/Kubernetes/Openshift, we deploy in the different CaaS.

Then, we have our bench testing session, where we test every part of the platform. We use a tool called TestLink for this task. Every member of Onesait Platform receives a set of tests to check some aspects of the platform. Also, our code has automatic tests to make simple functionality checks.

If our score is, at least, 95% and the failed tests are not critical, we change to the next version. The failed test become a new Gitlab issue which will be corrected in the next week version.

After finishing the tests, weekly branch is merged into master and then the following Jenkins pipeline is launched to generate the new weekly branch, the tag for this version and the milestone where the GitLab issues are allocated. It also sends a mail to the whole team with the new information about next week branch.