How Is our Release branching strategy?
We have 3 branches: dev, uat and master.
We are using Azure Devops
Dev will create a Feature branch cloned from master.
Dev commit updated to Feature branches and Create first PR to Dev
Dev create second PR to UAT
Feature is approved in UAT sandbox
Release Manager creates a Release Branch from master
Feature branches are merged with release branches *using Cherry picks or PRs
Release branch is deployed in Prod
New pr is created from Release branch to Master
Now, the problem is when dev creates a new Feature Branch cloned from master and submit their first PR to dev or uat branch for a new release cycle all the files and commits from previous release are displayed as new changes in files and commits tabs of the PR. I understand it is related to a commit ID not present in dev or Uat but I don't know how to avoid it.
Number of files and commits not related to a particular feature makes developers and reviewers concern.
Related
Azure Devops
Scenario : I have branch dev and master. There is commit in dev branch AS Commit1, Commit2, Commit 3 and Commit4 and all this changes release on dev site. Now I have approval for Commit1 and Commit3 to release on production. So how can I merge only commit1 and commit3 from dev branch to master branch
Important Note: I'm sure you know this but I think it's worth mentioning that you haven't actually tested exactly what you intend to release. You may benefit from having another branch, say release, where you put the stuff you decide to release, and then you can periodically reset dev to master to clean it up. (And if you do this I would consider calling dev something like next like gitworkflows, which is a similar concept.)
Solution 1 (Most General):
Create a new branch from master, cherry-pick the commits you want from dev, and merge this "release" branch into master.
Solution 2 (Works if your dev branch has merge commits for each commit brought into dev, and those commits' parent is master.):
Create a new branch from master, merge in each of the branches for the commits, and merge this "release" branch into master.
Solution 3 (Works if your dev history is linear after master, and if you never intend to bring in commit 2):
Disclaimer: this is more of an academic answer and I likely wouldn't actually use this solution in your scenario...
Create a new branch from master, and then perform 3 merges:
git switch -c release master
git merge Commit1 # take commit1
git merge -s ours Commit2 # merge commit2 but ignore it's changes!
git merge Commit3 # take commit3
# merge release branch into master
git switch master
git merge release
I have 3 branches:
develop
staging
main
I want that every new branch called feature-XXXX:
only can do PR to main it's already merged to staging
only can do PR to staging it's already merged to develop
My desire is to force that that PR be in order to be merged to develop, then staging, then main.
Is there a way to configure those restrictions?
I have a Release pipeline (Classic version) with artifact set to a Azure Git repo. The default branch is set to master branch. Every time someone creates a new release, latest version of master branch is copied to the Dev Ops agent and release tasks will run.
Is it possible to allow specification of branch at release creation time?
If I don't misunderstand, you would like to trigger release pipeline with specific branches.
You could try to add Branch filters.
A release will be triggered only if the Git push contains a commit on
the specified branch. For example, selecting "master" will trigger a
release for a Git push which contains one or more commits to the
master branch. To trigger a release for any commit to branches under
features/, enter "features/". To trigger a release for commits to all
branches, enter "". Note that all specified filters will be OR'ed.
For example, an artifact matching at least one filter condition would
be sufficient to trigger a release.
If you mean triggerring stages with specific branches, Artifact filters can do.
For more information, please refer to this document.
Been using production/integration branches to manage code promo to production. Our integration branch is a stable integration environment that all feature branches are made from, and merges are reviewed by PR, and deployed via CI when approved and squashed+merged. Once integration is stable and we've tested it, we do another PR from integration to production. When this is approved and squashed+merged, CI takes over and deploys to the production env.
git checkout integration
git checkout -b feature
# do work
git add/commit etc
# create PR, squash+merge on github UI when reviewed
# CI sees new commit to integration, deploys to int env
My issue is with what these integration -> production PRs looks like when they are reviewed - even though (at times) I've done the following to get any commits already in production into integration:
git checkout integration
git pull
git pull origin production
git push
# create PR for integration merge into production
When I go look at the PR page on Github, the list of commits shows history going back to commits that are already represented in production. The "Files changed" list is very small, while the commit history goes back many PRs ago. I thought git pull origin production would remove this history and then only show the new commits coming from integration to production?
Am I missing some obvious way to maintain merge commits but also clean up the history when integration is merged into production? Could inconsistent merging/rebasing strategies cause this?
Some screenshots to show what is confusing - a PR that has a single file changed from a single commit, but the commit history goes back much further:
The single file change was the last commit in the list—why does the PR show commits that have already been merged previously? I thought Squashing and Merging (both into integration from feature branches and into master from integration would remove this commit history and make merges into master clean?
The green arrow represents the 1 file changed in this PR, and I thought the commit history (after a merge of production back into integration to clean the history, if any) would only have that one commit.
Is this a github display bug or am I missing some principle of how git maintains commit history across a long-running branch that gets merged into another long running branch? It's always a one-way merge, from integration into production branch, for CI to deploy the update.
I have a question about two source control scenarios, both with feature branches and release branches:
In scenario 1 feature branches are merged to the trunk.
In scenario 2 feature branches are merged to the latest release branch.
What are the consequences of scenario 2 compared to scenario 1?
What are the possible advantages and disadvantages of both scenarios?
More details of the two scenarios:
all development is done in feature branches
branching is always done from the trunk
Scenario 1 (similar to what is described in this SO-answer):
feature branches are always merged to the trunk
a new release branch is created from the trunk, when preparations start for a new release
after QA and deployment from a release branch, the changes/bugfixes in the release branch are merged to trunk and newer release branches
changes to the trunk are merged to all feature branches
Scenario 2:
feature branches are always merged to the newest release branch
a new release branch is created from the trunk, when the current release branch no longer accepts new features and preparations start for final release
after QA and deployment from a release branch, the changes/bugfixes in the release branch are merged to trunk
changes to the trunk are merged to all feature branches and the newest release branch
Since branching is all about isolation (see "When should you branch), the difference between the 2 scenarios is the role you want the main branch trunk to have:
Scenario 2 is more adapted to a static role: trunk would be the representation of what is in production (and the occasional hot-fixes needed to be merge back to current feature and next-release branch)
Scenario 1 is more suited for a dynamic role: trunk is the integration for various feature, release branches being made from there to consolidate the features which will actually be part of the next release.