E2E Python solution in DevOps – Part 2: Release diagram

In this serie I show you how you can create a PyPi ready solution which is stored on GitHub and has fully automatized build-test-deploy CI/CD pipeline in Azure DevOps. Furthermore you will be able to use it from command line like azure-cli or aws-cli.

Table of content

• Part 1: Basic Python Code
• Part 2: Basic Release diagram (current)
• Part 3: Azure DevOps preparation
• Part 4: Create Azure DevOps pipeline – staging
• Part 5: Create Azure DevOps pipeline – master
• Part 6: Add test cases to project
• Part 7: Expand Python project functionality

Release process with Git branches

Before we start to create our super-automatized CI/CD pipeline we should stop a little bit and clarify how we handle releases, features, hotfixes in our project. So what kind of git branches we need and how we want to manage them inside and outside of our pipeline. It is important from stability, testing and quality point of view.

In our object-lesson we use a simple and “real-world” example.

In this release process we use 4 types of branches:

Master

Master branch contains the latest, stable code (and releases). This is a “read-only” branch which means:

• It is used by Ops team
• It is only used for PROD environment
• Origin of master code
• It is not allowed to modify directly by anyone
• Every modification come from Staging branch via Pull requests only
• It is the only supported version

Staging

Staging branch is an interim branch for testing and preparation to production. This contains all features and hotfixes but this is not actually a stable version. This means:

• You have to create Staging branch from Master branch
• It has to be tested (before create a pull request to Master branch)
• This is not supported code
• It mustn’t use for PROD environment
• It is not allowed to modify directly by anyone > read-only
• Used only for testing
• Origin of Feature(s) and Hotfix branches

Hotfix(es)

Hotfix branch‘s purpose is to manage the hotfix type development activities. This means:

• You have to create Hotfix branch from Staging branch
• You can create more than one hofix branch if it is necessary
• You have to test the hotfix before create a pull request to Staging branch
• You need to be careful with the dependencies of modifications with other branches such as Feature(s) and Hotfix(es)
• You mustn’t create new functions and features when you work in a hotfix branch.
• This is an editable branch
• This is not supported code
• It mustn’t use for PROD environment

Feature(s)

Feature(s) branch contains all new features and functions related modifications. This means:

• You have to create Feature branch from Staging branch
• You can create more than one feature branch if it is necessary
• You have to test the functions and features before create a pull request to Staging branch
• You need to be careful with the dependencies of modifications with other branches such as Feature(s) and Hotfix(es)
• This branch main purpose is to conains the new features and functions related codes
• You are allowed to create a hotfix for an existing issue if it is part of the new feature
• This is an editable branch
• This is not supported code
• It mustn’t use for PROD environment

Process summary

How does it work in real life?

1. Your stable code is always in master branch.
2. If you need to fix an issue or create new features you copy master branch to staging branch.
   1. If you want to fix an issue
      1. You create a hotfix branch from latest staging branch
      2. Fix issue
      3. Test hotfix
      4. Create pull request to staging branch
   2. If you want to create a new feature or function
      1. You create a feature branch from latest staging branch
      2. Create/Develop new things
      3. Test modifications (or all code)
      4. Create pull request to staging branch
3. Test modified code on staging branch
4. Create pull request to master branch

Please take care about change management and dependencies. For this you have some good helps such as Pull request related conflict management, Agile and Scrum methodologies.

That’s all for Today. Next time we start the implementation of this release process and our CI/CD pipeline in Azure DevOps. See you soon 🙂