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.
I am having a bit of trouble with the Branch Updater feature of Bamboo.
If a new commit is pushed on a branch that is using the branch updater, Bamboo checks if there are new commits on the dependent branch(in my case the master branch) and if this is the case it merges the changes and runs the build.
However, if this build fails, it is hard to recognize, if the new code on the branch itself is broken or if it just could not be merged correctly with the master. Therefore I would like that in these cases the branch is build independently first and only if this build is successful, the changes on the master are merged in and the branch is build again.
Is this possible using the branch updater feature?
A workaround might be to use multiple build plans and use one to build all branches isolated and another plan to integrate everything using the branch updater.
The "Branch Updater" feature is to merge the code from master branch into feature branch after a successful build of the master branch.
However, currently there is NO straight forward option in Bamboo (except the workaround mentioned in your OP) to build the branch and auto merge only if the branch build is successful.
Typically, the developer runs the build in local and commit the changes to repository if the local build is successful. There are two things that can go wrong.
1) While running the local build, the latest code from feature branch is not available in local. Some of the repos like GIT would complain if the local doesn't match with HEAD revision, you need to update to HEAD before you commit the changes. In this case, you can run the build again to ensure there is no problem.
2) When the master code merges with feature branch, something could go wrong
I understand that still there is a gap which can be addressed to resolve the point 2.
You can create a ticket in Bamboo with detailed explanation of the use case to add this feature.
Is it possible to make a release from custom branch (not develop)?
I tried to use startCommit command, but Maven JGitFlow plugin has been switched to the develop branch before release is started.
Also, when I changed git configuration manually, it was automatically changed to develop.
I would like to use following steps:
release-start - create release branch
release-finish - create tag, merge to the master and develop, update pom.xml versions.
Issue found
Create a branch from tagged version
Fix issues there
Make another release from that branch
It seems that the parameter startCommit (http://jgitflow.bitbucket.org/release-start-mojo.html#startCommit) is not enough because that provokes an exception with m5.1 (https://ecosystem.atlassian.net/browse/MJF-284). Using flowInitContext seems to work though (http://jgitflow.bitbucket.org/release-start-mojo.html#flowInitContext). You just have to adjust the develop branch (source branch for release branches) to point to your custom branch.
The only thing which cannot be achieved that way, is that during release-finish a merge back to the global develop branch is done. Usually you also don't want to merge back to master (since that may provoke git merge conflicts), which need to be resolved manually.
OK, I'm new to Mercurial and version control branching in general, so I may have a fundamental misunderstanding of what's going on here -- please be kind... ;)
We are a small development team (2 developers) working on a project, and we have a need to implement a fairly significant change that may take weeks or months. At the same time, the program is in daily use, so we have a need to make regular patches and fixes.
Because of the long-running nature of the significant change, I created a branch off the default branch (call it dev1). I will want to periodically merge the changes from the default branch into the dev1 branch, for reasons that don't need to be reiterated here. However, I do NOT want the changes from dev1 merged into the default branch until much later in the development.
I have tried several different ways to do this, but it always seems the merge affects both branches. After the merge, if I update to the default I now have changes from dev1 merged into the source.
Can I work on both branches using the same repository? If so, can someone please share the sequence of commands to use? If not, it seems to me I would not be able to push the dev1 branch up to the master repo until it was finished, and that just doesn't seem right.
We are running the latest TortoiseHg for Windows, and for the most part I love the graphical tool. However, I am perfectly willing to drop to the command line to do certain tasks when necessary.
Thanks for any help,
Dave
This depends on what sort of branch you've created.
If you have created a named branch, and are working in a single working directory, then you need to use one workflow, but if you have cloned your production repository, you need to use a different workflow.
Named branch workflow, single repo/working directory
In this case, you are using update to switch between the default branch and the dev1 feature branch.
When you want to work on the default branch, update to it, do your bug fixes, and commit those changes. Do not merge in changes from dev1 branch.
When you want to work on your dev1 branch, update to it, merge in your bug fixes from the default branch, work on your feature and commit when done.
If you are working on the dev1 branch and a colleague fixes a bug in default that you need, commit your work, fetch their changes, merge them in and then resume your work (there are shortcuts you can take here, but this way you can backout the merge if it gets messy)
Note: All of these assume that all of your changes are committed at the point you want to switch between dev1 and default branches.
The important thing to note is that you only get the changes from your dev1 branch in default when you merge them in. If you only merge default into dev1 then your feature branch will keep up to date with default so that when you are ready to deploy the feature into the default branch, you can do so with one simple merge operation.
Unnamed branch workflow using dev1 repo cloned from production repo
This workflow is similar, but allows you to work on the default and dev1 branches simultaneously, without having to update to switch between the two.
When you want to work on the default branch, use the repository where the tip is your production code. Do your bug fixes, and commit those changes just as you would normally.
When you want to work on your dev1 branch, use the repository where the tip is your dev1 feature branch. If there have been fixes in the default repository, pull in the changes and merge them into your clone, but do not push the merge changeset back. Only push your changeset back when you want to deploy you feature to production code. Once the changesets from default have been merged in, you can continue working on the feature.
If you are working on the dev1 branch and a colleague fixes a bug in default that you need, commit your work, fetch their changes from your shared repository into your default production clone, then pull those changes down into your dev1 feature clone, merge them in and then resume your work.
Again, the important thing to note is that you only get the changes from your dev1 branch in default when you push them up to your default production repository. If you only pull/merge default changesets into the dev1 clone then your feature branch will keep up to date with default so that when you are ready to deploy the feature into the default branch, you can do so with one simple push operation.
Yes, you can absolutely do this with Mercurial.
First, in case it isn't clear to you (it wasn't to me for some time), there are 3 types of 'branches' in Mercurial:
clone a repository
a 'named branch' (using the hg branch command)
an anonymous branch, which you can manage with bookmarks or just remembering the changeset
I'm guessing that you used the hg branch method. Be aware that this is often not what you want, because that branch name will live in the repo's history forever (well, there is the --close-branch option, but still...).
The essential workflow is:
update to dev branch with hg up devbranch
commit changes to dev branch
merge with main branch via hg merge default or just hg merge as desired
(repeat as desired)
And for working on the default branch:
update to default branch with hg up default
commit changes
(repeat as desired)
Do NOT do this:
update to default branch with hg up default
merge with dev branch with hg merge
I suspect that you are using the command hg merge without specifying a branch name. That will merge with any other head, which may or may not be what you want.
Edit: The above info is probably not your issue. Your issue is probably running a merge when your current branch is the default one.
You don't want to run hg merge from your default branch.
# bang on dev1
# more banging on dev1
# someone beats on default for a while
# update to dev1
hg up dev1
# bring in the changes from default
hg merge -r default
# validate successful merge
hg commit -m "merging"
The key is committing on dev1 when you bring changes over from default.
Note that I'm using named branches here.
This sentence:
After the merge, if I update to the default I now have changes from dev1 merged into the source.
tells me that you're doing something wrong. It is perfectly doable what you want to do, work on two branches in parallel, and merge from one to the other, without influencing both.
It is important to know that the merge is a directional merge. You merge from one branch to the other, and when you initiate the merge, you should be on the to-branch.
directional in the sense that the direction plays a role in the outcome. For the actual contents of the file, it doesn't matter which direction you merge, but the new merge-changeset you commit will be on the branch you was on when you initiated the merge (unless you override.)
So, update to the head of dev1 first, then merge with default, and after committing, you should have a new changeset on the dev1 branch, but default should be left undisturbed.
This is more of a tip than an answer, but...
I use this workflow a lot. I find the Transplant extension very useful for named branch workflows. TortoiseHg supports it, so you can enable it in the TortoiseHg options. It lets you cherry-pick from other branches, which is very useful - especially if you regularly commit to the wrong branch.
How do you handle versioning in a continuous integration environment where there is a development branch and a release branch? I'm using git so there is no incrementing repository version to use. Seems like there will be overlapping versions such as 1.1.0 on the dev branch and 1.1.0 on the release branch. Do you just append the text "dev" or "release"?
Also, when you create a release branch do you immediately increment the development branch to the next "proposed" release number? You may not know the next release number yet but if you don't increment it then you have 1.1.0 dev containing new work not included in 1.1.0 release.
So my main question is what is the relationship in the versioning sequences between these two branches?
Keep in mind, I'm not asking anything about how to decide what version numbers to use. I tried asking this before and kept getting comments like "increment major for breaking changes" etc.
I don't version the dev branch. The devline is the trunk and I periodically branch from dev to a new release folder. So the release branch is full of folders which are basically snapshots of the devline.
IE, under root I have /dev, /releases/0.1, /releases/0.2, /releases/1.0, etc.
I'm not sure if this really answers your question.
I would recommend set a final activity for your CI environment to make tags. I believe the git command looks like this: git tag -a name
We use Major.Minor.Release.BuildNumber
though some places use Major.Minor.Release.CheckinNumber
So, if you want to use that then I would version your dev branch, otherwise just version the release branch.
If you have only one development branch, it is more effective to make it be the trunk and branch off a release branch every time you just want to stabilize for release. If you have multiple feature projects, you can have a branch for each of them with CI setup on those. Once they are done, you merge them one by one to the trunk and once all are merged, you get to the first scenario, where you branch a release branch off of the trunk again.
In any case, you don't keep the development branch going between releases. You want to end it and start a new one for development for the next version. This way some of the features can be branched off during several releases if they take longer. But also you don't have too much mess on your development branches.
You can branch the development branches for the next version as soon as you branched the release branch or even before if you chose to, but it is generally good idea once you stabilize for release, merge the changes from release branch into trunk and from there into the development branches if you do that. If you wait with branching off after release, you avoid few merges there, but you slow down development.