Separate Master branch with respect to Production Environment and Add New Staging Environment

[Prajwalprakash3722]

We currently have a single Master branch in our repository that will be used for both production and staging env. However, we would like to separate the Master branch into two distinct branches - one for Production and one for Development. This will help us better manage our codebase and ensure that changes made in the Development environment are thoroughly tested before being deployed to Production.

In addition, I would like to create a new Staging environment to test changes before they are merged into the production branch. This will allow us to catch any potential issues or conflicts before they impact the Production environment.

changes proposed:

• Keep the master branch as production branch, This branch will only be used for Production deployments.

• Create a new branch called staging from the current Master branch, This branch will only be used for Staging deployments.

• Update our deployment processes to use the appropriate branch for each environment.

Workflow is as follows, All the members shall take a PR request to staging branch and have a review and merge it, when the staging branch is stable we shall take a PR with master branch and merge it :) [Two Branch Workflow]

graph LR
    A(Members) --> B(Staging)
    B --> C{Pull Request}
    C -->|Review and Merge| B
    B --> D(Staging Environment)
    D --> E{Test and Validate}
    E -->|Approved| F(Master)
    F --> G(Production Environment)

Loading

• A developer creates a new branch off of the production branch to work on a new feature or bug fix.
• The developer makes their changes and creates a pull request to merge their branch into the staging branch.
• Other developers or team members review the pull request, make comments or suggestions, and ultimately approve or reject the pull request.
• If the pull request is approved, the changes are merged into the staging branch and the code is tested in the staging environment to ensure that it is stable and does not introduce any bugs or conflicts.
• Once the changes have been thoroughly tested in the staging environment, a new pull request is created to merge the changes into the production branch.
• The pull request is reviewed and approved, and the changes are merged into the production branch and deployed to the production environment.

[Prajwalprakash3722]

FYI @MayurSChittaragi @chrisvrose @naveenbteli @sannidhi-s-shetty!

[chrisvrose]

When we say staging env - I understand its like a dev env, before we actually deploy to prod. Here are some questions that should be answered -

1. How do we regularly deploy this env?
2. Which apps will actually need this now? All, or can we limit to only ones which need to be rock-solid stable?

Less important questions:
3. Hardware wise, can we share resources with our existing server? Would like to not use too many resources, since after all we're running on free resources.
4. Can this process be explained and followed easily for someone new, and they can take over within a year?

[Prajwalprakash3722]

You are correct, a staging environment is typically used as a pre-production environment where changes can be tested and validated before being deployed to production.

To answer your questions:

• The regular deployment process for a staging environment can be done on successful merge to staging branch.

• Our resources are limited, So it may be possible to limit the staging environment to only those applications that require more testing and validation.

  • Loot ledger
  • Site Rear

• To ensure that the staging environment can be easily maintained by someone new, it is very important to have detailed and clear documentation of the deployment process and any specific configuration requirements for the applications being tested.

  • we have deploy manifest where configs will be explained and documented
  • we Shall write a new documentation explaining the staging env to anyone new

Additionally I had some idea regarding how to automate the entire process and also learn something along the way, I researched and found about Jenkins and Ansible these tools we can try and learn and use them to our requirement and these can help to simplify the deployment process and ensure that it can be easily followed by someone new.