зеркало из https://github.com/microsoft/AL-Go.git
Branching strategy
This commit is contained in:
Родитель
751cccc43a
Коммит
8b1203de11
|
@ -26,6 +26,7 @@ Usage scenarios:
|
|||
13. [Set up your own GitHub runner to increase build performance](Scenarios/SelfHostedGitHubRunner.md)
|
||||
14. [Introducing a dependency to another GitHub repository](Scenarios/AppDependencies.md)
|
||||
15. [Enabling Telemetry for AL-Go workflows and actions](Scenarios/EnableTelemetry.md)
|
||||
16. [Branching strategies and some of the best practices](Scenarios/BranchingStrategy.md)
|
||||
|
||||
**Note:** Please refer to [this description](Scenarios/settings.md) to learn about the settings file and how you can modify default behaviors.
|
||||
# This project
|
||||
|
|
|
@ -0,0 +1,45 @@
|
|||
##Branching strategy##
|
||||
A version control like Git gives you flexibility in how you share and manage code. **Your team should find a balance between this flexibility and the need to collaborate and share code.**
|
||||
|
||||
Adopt a branching strategy for your team that is flexible and yet easy to adopt by your team. You can collaborate better and spend less time managing version control and more time developing code.
|
||||
|
||||
###Keep it simple and relevant###
|
||||
Keep your branch strategy simple and relevant to your needs. If your team is small and collaboration is limited, a simpler branching strategy will be a better option. When choosing a branching strategy, pay attention to these three concepts:
|
||||
|
||||
- Use feature branches for all new features and bug fixes.
|
||||
- Merge feature branches into the main branch using pull requests.
|
||||
- Keep a high quality, up-to-date main branch.
|
||||
read more here https://docs.microsoft.com/en-us/azure/devops/repos/git/git-branching-guidance?view=azure-devops#keep-a-high-quality-up-to-date-main-branch
|
||||
|
||||
###Use a feature branch###
|
||||
A CI/CD workflow runs when a pull request is created. In this case the artifacts should NOT be published from a feature branch (ignore the CD part of the workflow).
|
||||
|
||||
CI/CD workflow also runs when a pull request is merged to main branch. Use the artifacts generated in this workflow to create a release. CD part can use the artifact generated in CI, for example to deploy them to a sandbox environment.
|
||||
|
||||
Read more about use of feature branches and pull requests here https://docs.microsoft.com/en-us/azure/devops/repos/git/git-branching-guidance?view=azure-devops#keep-your-branch-strategy-simple
|
||||
|
||||
###Use release branches###
|
||||
Release branches help you to stabilize your changes and give you more control on the code used in different environments. This branch is long-lived and **isn't merged back into the main branch in a pull request**, unlike the feature branches. Create as many release branches as you need or if you need to keep it simple create one. Keep in mind that each active release branch represents another version of the code you need to support. Lock release branches when you're ready to stop supporting a particular release.
|
||||
|
||||
AL-Go system supports release branches with the following format "releases/<release name>" e.g., releases/19.2. A CI/CD will be run when a change is pushed to a release branch.
|
||||
|
||||
A simple solution is to create a release from the latest or a given build from main or a release branch. Do not use a feature branch to create a release. For a more advanced scenario create prerelease and then promote it to a release.
|
||||
|
||||
If you decide not to have release branches, you can create a release from main, make sure that changes in main are always tested before getting merged and keep a high quality, up-to-date main branch.
|
||||
|
||||
Read more about release branches here https://docs.microsoft.com/en-us/azure/devops/repos/git/git-branching-guidance?view=azure-devops#use-release-branches
|
||||
|
||||
####Hotfixing an issue in a release####
|
||||
|
||||
The best approach to fix an issue in a release branch is to start by fixing/testing it in main.
|
||||
|
||||
Then you can create a pull request by cherry picking the changes and merge it to a release branch. A release can be created from the artifacts generated by CI/CD when changes are pushed to a release branch. If you have multiple release branches, repeat the same process for each release branch.
|
||||
|
||||
**Useful links**
|
||||
Read more about flow and some of the basic terminology here https://docs.microsoft.com/en-us/devops/develop/how-microsoft-develops-devops
|
||||
|
||||
Here you can find useful information about branching patterns and anti-patterns https://youtu.be/t_4lLR6F_yk
|
||||
|
||||
|
||||
---
|
||||
[back](/README.md)
|
Загрузка…
Ссылка в новой задаче