So i have master (Main Branch) and develop as long lived branches, i want to derive a feature from develop, this means that the project will merge with develop and not master.
Currently i am passing the arguments:
sonar.branch.name=feature-abc
sonar.branch.target=develop
This gets ignored and i get "feature-abc from master", is there a way to force a branch to derive from a branch?
Related
I have referred the article: https://learn.microsoft.com/en-us/vsts/git/concepts/git-branching-guidance?view=vsts for knowing more about Branching concept. And if my understanding is correct, there should be a master branch, then a release branch then a support branch and a feature branch in common.
And the merging between the branches should be defined as below:
Create the master branch(with code added to it).
A release branch is then created from the master branch(else know as a topic branch).
Then create a support branch to fix bugs from the release branch and then merge them back into the release branch in a pull request.
Create a new feature branch off the master branch to port the changes. Cherry-pick the changes from the release branch to your new feature branch. And then merge the feature branch back into the master branch in a second pull request.
Coming to the question, assume that i have 4 environments, such as - Development, Test, Pre-Production & Production. Here i need to have a branching and merging mechanism and needs to setup cicd pipeline in VSTS.
How will i define the CICD pipeline for the above above case, if i use MS recommended branching and merging mechanism? Whether all the deployments will be done from the master branch only? (That's from Master branch, build & deploy to-> Dev -> Test -> Pre prod -> Prod environment?). Do i need to note of any other things in this?.
Or do i need to have a separate branching and merging mechanism, such that i need to have separate branches for each of the four environments and should define separate pipelines like the below screen?
For the standard branching model, you can refer A successful Git branching model. It's a wide used branching structure which is also applied for gitflow. And based on the branching model, you can CI/CD to dev environment (by develop branch) and production environment (by master branch). If you design to deploy four environments separately, you can adjust the branching model correspondingly.
And each environment is for a single branch only. Such as for Dev environment, the CI/CD aims to check the code from develop branch. Only when the code from develop branch has been qualified, you can merge it into master or create a release branch to prepare the next release for production.
So while this is completely do-able (albeit using some fairly fancy scripting) in Jenkins, I'm just wondering if it's do-able in VSTS.
I'm not too familiar with capabilities of VSTS (have read https://learn.microsoft.com/en-us/vsts/build-release/actions/ci-build-git).
I want all changes pushed from a feature branch to master to be automatically merged into all other active feature branches. So basically, I want (what I call) true CI.
Is this possible in VSTS, and if so, how would I do it?
EDIT 1:
Read this:
https://learn.microsoft.com/en-us/vsts/build-release/actions/scripts/git-commands#merge-a-feature-branch-to-master
This would work for me by simply switching the merge direction; instead of merging from feature branch to master, merge from master to feature branch.
So the question now becomes:
How to get a list of all active child branches?
Given that I'll be using work items mapped to branches, would this suffice?
https://learn.microsoft.com/en-us/vsts/report/extend-analytics/work-item-links
No, it is not supported in VSTS, with Pull Request it just can merge source branch to a target branch.
The workaround is that you can create the Pull Requests for related branches during the build/release, refer to this thread for detail steps:
How can I create a Pull Request when a release completes in VSTS?
Update:
The other way is calling git command to merge branches: Merge a feature branch to master
Regarding active branch, as we discussed, you can link them to a work item, the work item has the TO DO, In Progress etc... states that can identify different "state" of branches, and you can retrieve the work item through Work Item REST API.
Doing trunk based development to achieve continuous deployment. And this is our branching strategy.
master > whats live in production
release > test passed and release point created by CI server
dev > daily merges from the development team.
If we consider doing the pull request from release to master stage.
What are the pros and cons to that approach? How can we communicate this with the development team where they want to do PR at dev branch?
I don't really have an answer, but think the context of the question is worth further discussion.
If you're doing Continuous Deployment, then I'm not sure of the purpose of the Release branch. It seems to be duplicating the purpose of either:
'master': code being deployed/released
'develop' integrated feature
branches, but not ready release
Or, are you using it to group milestones or planned major releases (i.e. Release/1.0, Release/2.0), like a mini-master branch.
I would not consider this Continuous Delivery (deployment, maybe), but it is certainly a valid pattern if your project requires staged releases rather than Continuous Delivery.
It's also important to also consider your CI setup and how it integrates with your branches. It isn't source code that is deployed to Production, but the build artifacts from your CI system. Thinking about this might simplify your branching model.
If you want to rollback, you don't want to rebuild the application from source, you want to re-deploy the pre-built artifacts of the previous version. Likewise, if you have a build that has passed all your tests and is ready to ship - hopefully is already running on your pre-production environments - you don't want to merge it to a different branch, rebuild it and then deploy the new build - you use the build that was tested.
The next consideration is that every additional branch adds time & complexity for the developers. Merging, pull requests, waiting for CI to run, etc. are not free so reducing the complexity of the branching strategy to the minimum you require is a good goal.
To answer your question about where to PR to/from, do you consider "Develop" as the mainline and attempt to keep it stable and working at all times?
If so, then the PRs from feature-to-develop are the key integration. Develop is then built, tested, and deployed to your test environments.
Branching from develop at that point (i.e. to create a Release branch) is then known to be good.
Promoting that artifact from your test environment to production, without re-building, might remove the need for one of your branches.
When I was using
mvn jgitflow:release-finish
I noticed that the release branch got merged into master branch.
Question: Is this the correct way?
Sorry my questions might be naive as I am new to this. I was thinking that the code from release branch will merge to develop and master and not like release --> master --> develop.
Question: What if I don't want this to happen and instead I should be in a position to rebase develop from master?
When I was using mvn jgitflow:release-finish I noticed that the release branch got merged into master branch. Is this the correct way?
This is the correct way according to the main philosophy behind, gitflow:
Release branches
May branch off from:develop
Must merge back into: develop and master
And according to the plugin documentation, the release-finish indeed merges back to the master and dev branch:
finishing a release - runs a maven build (deploy or install), merges the release branch, updates pom(s) with development versions
This makes sense, because (again back to gitflow):
When the state of the release branch is ready to become a real release, some actions need to be carried out. First, the release branch is merged into master (since every commit on master is a new release by definition, remember). Next, that commit on master must be tagged for easy future reference to this historical version. Finally, the changes made on the release branch need to be merged back into develop, so that future releases also contain these bug fixes.
I was thinking that the code from release branch will merge to develop and master and not like release --> master --> develop.
The order follows this flow (first master, then develop) because it's a release and as a release it must firstly go to master (which should always represent the released code base), then to develop (whish is the next potential release code base).
What if I don't want this to happen and instead I should be in a position to rebase develop from master.
You can use the noReleaseMerge option:
Whether to turn off merging changes from the release branch to master and develop
Default value is to false, hence by default merges are performed. However, the option covers the two merges, you cannot disable only one of them, it's either both (again, following gitflow philosophy) or none. This option may suit your needs but you would then perform additional actions via git commands.
i have an open source ruby project on github, where my master branch represents what has been released, and my dev branch represents what will be released next.
the master branch is ~ 80+ commits behind the dev branch, and the dev branch contains fairly significant architectural changes.
a contributor has sent me a pull request for changes that were made based on the master branch. i want to pull those changes into my dev branch without having to re-write them or do a ton of merge conflict resolutions (which would essentially be rewriting the changes anyway).
what are the best practices for handling a situation like this?
One solution would be:
"Any patches that doesn't apply in a fast-forward manner is rejected."
You could ask your contributor to fetch your dev branch and to replay (rebase) his/her relevant commits on top of the fetched dev branch.
Once those changes works in that dev environment, then he/she can make a new pull request.
That way, you report the extra work on the contributor, and once this refactoring is done, you can enjoy the contribution by applying it simply on top of your current dev.