I need to make a software release but I'm having issues with non consecutive changesets. I have almost 20 of them that need to pass from testing environment to production and I've already looked for many solutions.
My main problem is that I'm trying to keep Production branch clean so I want to merge all of those 20 changesets but push them to production as a single commit. I think it will also be easier to rollback if needed. Thing is that you cannot merge a changeset if it detects conflicts on another merge that is yet to be check-in.
Any ideas on how to do this?
Well you can't merge changeset directly. It's impossible. Could you create a independent branch for this situation.
Related
The current workflow for our developers is
Create a new branch from develop for each bug
Make your changes, and commit them
Create a Pull request
The issue :
I am working on bug 1, branch name develop_bug1 . I commit my changes in the file file1.jsp and create a PR
I now start working on bug 2, branch name develop_bug2. I find out that changes need to be made in the same file file1.jsp as bug 1. When I checkout develop_bug2, my changes from develop_bug1 aren't present.
What if I finish my changes for bug 2 and commit and create a PR? Will it overwrite changes for bug 1?
Not sure where to start
Changes on the two branches will not be present in the other branch or the develop branch until the two bug branches are merged. They are entirely separate ‘copies’ of the code.
Because both involve changes to the same file (file1.jsp) there are going to be so-called merge conflicts, which need to be managed.
Let’s assume that develop_bug1 is to be merged back into develop first (either because it is more urgent or because is has less changes).
Step 1: Merge develop_bug1 into develop. There will be no conflicts.
Step 2: Merge develop into develop_bug2. This is sometimes called rebasing. There will be merge conflicts which you will need to resolve. Your IDE will help you deal with the conflicts by selecting which version of each change to accept.
Step 3: Merge the updated develop_bug2 (which now includes changes originating in develop_bug1) into develop. There will be no conflicts.
If none of the PRs gets merged, then there are no conflicts in both of two branches.
If one of the PRs gets merged, then the second PR will get conflicts, we should resolve the conflicts first, push to remote, and then the second PR could be merged.
PS: always pull the lasted code into local branch before we raising a PR.
Our team started using TFS few months back and we are learning as we progress. We first checked in our existing code to TFS thereby creating a Main Branch. We then created a Development Branch from this Main branch.
We just did a release and I merged Development branch with Main. It asked me to map Main branch folder on my workstation. Done that Merge completed successfully. But after merge I noticed on server that change sets are still old and source code on server has not changed.
looking further I noticed that the changed file is marked as 'merge pending'.
When I opened solution from mapped folder of main branch, I did see that all changes from Development branch merged to Main are in pending state.
Questions
Do I always have to check in pending changes after each merge in TFS
Is is possible to merge source code on server instead of from
workstation (All code in development is in Checked in state).
I am using VS2012 (if that matters)
Please advise, especially if I am taking a wrong approach with TFS.
In answer to your questions:
Yes, you always have to check in pending changes. Pending changes are local to your machine, they give you the chance to review the result of the merge locally before they are committed to the server. This is especially important because the merge may result in a conflict that you need to resolve before you can check in.
I don't think that this is possible (although I never researched this specific question). This is, again, because of the possibility of a conflict that needs to be resolved manually. Even if you perform a merge programmatically via the TFS API, the merge will happen locally.
Don't worry, you are doing the right thing. Only one word of warning regarding merges in general: Before you attempt a merge, always make sure that you perform a "get latest" operation on the target branch! The source branch does not need to be up-to-date on your local machine because the merge operation will get the source branch data from the server. But the changes will be merged with whatever version your local target branch files have, so if these are not up-to-date you will get unexpected results.
I've been doing some reading about continuous integration recently and there is a scenario which could occur which I don't understand how to deal with appropriately.
We have a stable mainline/trunk branch and create branches for features. Each developer will keep their own feature branches up to date by merging from trunk into their branch on a regular basis. However it is entirely possible that two or more feature branches could be created and worked on over a period of several weeks or months. In this time many releases of the software could be deployed. This where my confusion arises.
It is very likely that changes for one feature branch will cause merge conflicts with other feature branches. CI suggests you should merge into trunk at least daily which would resolve the conflicts quickly. However, you may not want to merge the feature code into trunk because it may not be finished or you may not want that feature available in the next release. So, how do you deal with this scenario and still follow CI principles of daily code integration?
There are no feature branches in proper CI. Use feature toggles instead.
The idea explained more fully in this article is to merge from the trunk/release branch to feature branches daily, but only merge back in the other direction once a feature meets your definition of 'done'.
Code written by one feature team will be pushed into the trunk once it's complete, and will be 'distributed' to the other teams, where conflicts can be dealt with, as part of the daily merge process.
This doesn't go as far as satisfying Nick's desire for a version control system that can be used a backup tool, unless the changes being made are small enough that they can be committed to the feature branch within a timeframe where the the risk of losing your work is acceptable.
I personally don't try to reintegrate code into the release branch before it's done, and although I've never really tried, I'm sure building feature toggles in for unfinished work has its own issues.
I think they mean merging mainline into the feature branch, not the other way 'round. This way, the feature branch will not deviate from mainline too much, and be kept in an easily mergeable state.
The git folks do the same thing by rebasing feature branches on top of the master branch before submitting a feature.
In my experience with CI, the way that you should keep your feature branches up to date with the main line changes as others have suggested. This has been working me for several releases. If you are using subversion make sure you to merge with the merge history enable. This way when you are trying to merge your changes back to line it will only like you are merging the feature changes to line, not trying resolve conflicts which your feature might have with the main line. If you are using more advance VCS like git the first merge will be a rebase where the second will be a merge.
There are tools that can support you to get thins done more smoothly like this Feature branches with Bamboo
Feature branches committing back into the mainline, and OFTEN is an essential feature of Continuous Integration. For a thorough breakdown, see This Article
There's now some good resources showing how to combine both CI and feature branches. Bamboo or Feature Branch Notifier are some ways to look.
And this is another quite long article showing pros of so called distributed CI. Hereunder, one excerpt explaining the benefits:
Distributed CI has the advantage for Continuous Deployment because it keeps a clean and stable Mainline branch that can always be deployed to Production. During a Centralized CI process, an unstable Mainline will exist if code does not integrate properly (broken build) or if there is unfinished work integrated. This works quite well with iteration release planning, but creates a bottleneck for Continuous Deployment. The direct line from developer branch to Production must be kept clean in CD, Distributed CI does this by only allowing Production ready code to be put into the Mainline.
One thing that still can be challenging is keeping the branch build isolated so that it doesn't pollute your repository of binaries by pushing its branch builds to it. Bamboo seems to address that, but not sure it's as easy with Jenkins.
We're considering a switch from SVN to a distributed VCS at my workplace.
I'm familiar with all the reasons for wanting to use a DVCS for day-to-day development: local version control, easier branching and merging, etc., but I haven't seen that much that's compelling in terms of managing software releases. Here's our release process:
Discover what changes are available for merging.
Run a query to find the defects/tickets associated with these changes.
Filter out changes associated with "open" tickets. In our environment, tickets must be in a closed state in order to merged with a release branch.
Filter out changes we don't want in the release branch. We are very conservative when it comes to merging changes. If a change isn't absolutely necessary, it doesn't get merged.
Merge available changes, preferably in chronological order. We group changes together if they're associated with the same ticket.
Block unwanted changes from the release branch (svnmerge block) so we don't have to deal with them again.
Sometimes we can be juggling 3-5 different milestones at a time. Some milestones have very different constraints, and the block list can get quite long.
I've been messing around with git, mercurial and plastic, and as far as I can tell none of them address this model very well. It seems like they would work very well when you have only one product you're releasing, but I can't imagine using them for juggling multiple, very different products from the same codebase.
For example, cherry-picking seems to be an afterthought in mercurial. (You have to use the 'transplant' extension, which is disabled by default). After you cherry-pick a change into a branch it still shows up as an available integration. Cherry-picking breaks the mercurial way of working.
DVCS seems to be better suited for feature branches. There's no need for cherry-picking if you merge directly from a feature branch to trunk and the release branch. But who wants to do all that merging all the time? And how do you query for what's available to merge? And how do you make sure all the changes in a feature branch belong together? It sounds like total chaos.
I'm torn because the coder in me wants DVCS for day-to-day work. I really want it. But I fear the day when I have to put the release manager hat and sort out what needs to be merged and what doesn't. I want to write code, I don't want to be a merge monkey.
You really want to be using git in this situation, because it is so vastly superior when it comes to merging and release management. Git allows for a signoff process for changes to go to release; it actually provides support for multiple layers of release management, precisely because that is how Linux is managed.
Simply put each release in a branch. Instead of blocking out changes you don't want, accept only those that you do, by only signing off for release those changes that are going into a release.
Git also allows you to cherry-pick a collection of changes into a single patch to be sent upstream, so you don't have to carry all the 'oops, that didn't quite work' patches into the release branch or repository, only nice clean feature or fix patches.
For personal projects I use Git for SCM, but at work we use TFS. One thing that I like about Git is that it allows a person to easily squash all the changes made in a branch when pulling the changes back into the master branch.
The benefit of this is that if their is anything wrong with the changes they can easily be removed be reverting back to the version before the merge even if no tag was created.
Is this. or the equivalent possible in TFS? Is this where shelving changes fits into the equation?
Thanks.
Performing a merge in TFS results in a single commit; all of the changes from the source branch get rolled up into one changeset pended against the target branch. So as far as I understand your question, the answer is "yes".