Skip to main content
Version: Next

Delivery Process Defintions:

Existing release/develop will act as main branch where complete code is maintained.

alt text

  1. Starting day of the sprint - new branch named release/release_version_number should be created from release/develop branch in Bitbucket. [Ex., release/12.2.0] Action on: PoD Lead/Team is responsible to create release specific branch as applicable.

  2. Developers will create feature branches from release/12.2.0 and works in respective feature branch to develop the feature in Local environment.

  3. While developing, Dev Team must ensure the JIRA ticket is tagged with appropriate release version and if there is any dependency with CMS, ensure that CMS JIRA ticket is also tagged under same release by taking confirmation from CMS Team.

Action on

PoD Lead and Team is responsible to finalize the release version. This will help developers to commit the code in release specific branches appropriately.

  1. After completion of the development with unit testing, Developers create PR from feature branch and merge the code in release/12.2.0 branch. Ensure codes are considered for PR merging is applicable for 12.2.0 release only.

Action on:

Dev team : Up on PR creation, Developers must ensure Sonar build is successful in Bitbucket/SonarQube before intimating Reviewers to approve the PR. Dev team : If any sonar build failure, it should be addressed immediately or should be discussed with PoD Leads to take any deviation approval. Up on Sonar build successful, do intimate reviewers. PoD Lead : Must ensure the PR raised against JIRA task is applicable for target release branch before approving. Must ensure sonar build status against the PR raised before approving.

  1. Tag the code from release/12.2.0 branch with “dev-” prefixed to deploy the code in DEV environment. Sanity/integration testing should be in done in this environment.

Action on: PoD Lead/Team is responsible for this activity.

  1. Developers must create PR from feature branch and merge the code in release/develop branch as mandatory step. Action on: PoD Lead/Team is responsible for this activity.

  2. Tag the code with “tst-” prefixed to deploy the code in TST environment from release/develop branch only. EY QA will test the feature in TST environment before releasing to AOK. Action on: Release Management Team is responsible for TST tagging.

  3. Based on Release Management Team confirmation, BE services will be tagged from release/12.2.0 branch for SAPW deployment. There is no change in SAPW tagging process. Action on: Release Management Team is responsible for TST tagging.

  4. Bugs identified in SAPM/SAPW/PROD environment as part of v12.2.0 release, fixing should be done in release/12.2.0 branch and tag the code with “dev-”, “tst-” and SAPW deployment/testing respectively. PoD Development team must fix this issue on top of release/12.2.0 branch and tag with “tst-“ for TST environment testing. SAPW tagging should happen from this release specific branch only. Development team must create PR from feature branch and merge the fix in release/develop branch as part of bug fixing activity.

Release management Activities needed in Confluence :

documentation is required in Confluence (https://confluence-extern.plus.aok.de/display/PLATT/NAVIDA+SAPW+Deployment). The deployment takes place every Wednesday. For this purpose, a subpage is created that documents all services, their respective versions and, if necessary, Helm chart changes. The Confluence page forms the basis for the deployment assignment at ITSCare

Secondly, a commit tag is required in the Bitbucket on the commit, which is to be released to ITSCare on SAPW. The release pipeline automatically creates a Helm package from the contents of the 'CD/helm' directory