Environment structure

Ideally, there should be 3 separate environments: Production, Staging and Development for different purposes:

• Production: Final product goes here
• Staging: UAT
• Development: For dev team and QA

Depending on the project, Staging can be skipped; UAT will be on Development.

Environment infrastructure

AWS should be the best option to host environments; specifically AWS Elasticbeanstalk which allows to programmatically deploy source code by provided command line.

Each product / service should be associated with only one application on AWS Elasticbeanstalk with 3 environments described in the previous section.

If the infrastructure is provided or defined by the client, follow their deployment reference.

Source code repository hosting

Bitbucket and Github should be prioritized as they enable CI / CD in projects (Bitbucket Pipeline and Github Actions) with strong build machines.

AWS CodeCommit and GitLab could be good options in case Bitbucket and Github cannot be chosen.

Credentials to repositories will be provided by project managers or tech leads.

Repository structure

Identical to environment structure, there should be 3 separate branches for 3 different environments:

• master: For Production
• staging: For Staging
• dev: For Development

Deploying right branch to right environment infrastructure MUST be 100% accurate. Otherwise, crashes will likely happen and degrade end users' experience.

Project members

Ideally, each member in the dev team should be invited to the repository with their Offspring Digital email for security and audit purposes.

There will be a case that the client's budget is not able to afford the cost for source code hosting. Therefore, Offspring Digital main account will be used to commit changes.

Branch permissions

master, staging and dev cannot be rewritten history. No force push can be pushed to those branches.

Only the team lead has permission to merge pull requests into branch master and staging after code review.

Branching and merging strategy

Devs checkout new branches from master to work on new tickets / issues. Name for new branches can be the ID number of the tickets / issues.

After QA, devs create pull requests into master and staging. Team lead is responsible for merging pull requests.