Design Patterns and Practices for Code Deployments

Branching strategies

Keeping your branching structure as simple as possible is imperative in helping to avoid over-complicating it unnecessarily. You’ll want to expand the strategy only as needed. You may need to have a more complex branching strategy if the implementation has a lot of customizations.​

Generally, you will want to start with at least a three-branch strategy: one for development, one for testing, and one for releasing your code to the production instance.​

Each of the code branches will relate to one or more environments in your implementation. For more complicated branching strategies and different approaches or management strategies, see the reference links at the end of this module.​


Code deployment flows

Perhaps the code is needed for additional functionality that is not important for the immediate future. These are some considerations that will help you determine where to deploy your code.​

In general, you’ll want to move the code in environments, that is, from development environments where it has been verified to a testing environment where multiple users can run through the process that you have modified. After the code has been tested, you will want to move it to a release or staging environment that will prepare it to be moved to production. In finance and operations apps, the code will need to be deployed into a Tier 2 Standard and Acceptance Test environment, and then selected as a release candidate before it can be promoted to the production environment to ensure that it has been validated.​

In the branching and code flow strategies that you develop, you will need to remember that these can change throughout the implementation, but planning for the changes is imperative to keeping the end goal of the implementation in mind.​