Intro:
Dev branch has the code that is deployed to the development environment and where development happens, QA branch is what gets deployed to the QA environment so QAs can test.
My question is:
After I am done working on the code in the Dev environment and has checked it into the Dev branch. What is the easiest way to move the changeset (or the code I have changed in Dev) from the Dev branch to the QA branch?
You appear to be very new to Source Control and Branching and Merging process. The process of moving one changeset (or a range of changesets) from a branch to another is called merging.
I suggest you look into Merge Folders and Files on MSDN that explains how to perform a merge.
Other excellent resources that might aid your understanding are the Wrox ALM and TFS books and the ALM Rangers Branching and Merging Guidance (in increasing in technical level order).
Related
We have multiple stand-alone hybrid dev/test teams, each with their own environments where code is written and tested as a complete unit. When an environment is in a tested deployable state, they merge from their main branch to an Integration branch. We also have a true test environment where we can do full end-to-end testing of the entire ecosystem before moving to production.
Here's an abbreviated diagram of the structure:
Does TFS have an automate a process where any changes checked in to the _Pretest branch would be merged to the team branches? I would prefer that if one team breaks what another team is doing, we break it in a dev environment and as early as possible.
(I know a big part of the answer is unit tests... we're working on it!)
There is no automated process for merge on TFS because merge may contain conflicts. But you may use "tf.exe" utility with command merge: https://learn.microsoft.com/en-us/vsts/tfvc/merge-command?view=vsts
tf merge branch2 branch1 /recursive
I am new to TFS. I read some articles on branching and merging features in TFS.
I wanted to know for my scenario how the branching and merging features of TFS can be used.
I have a Development branch. There are 2 features branches also created based on Development branch. Some developers have checked-in their code in Feature 1 and Feature 2 branch. Now, Feature 1 branch is merged in Development branch and Feature 2 branch is yet to be merged in Development branch.
How will the Feature 2 branch get the code of Feature 1 branch.
Will get latest version work for this?
Some of my friends suggested that first Feature 2 branch will need to get merged in Development branch and then the Development branch should be merged back to Feature 2 branch.
Its quite confusing for me as I want that once I have checked-in my Feature branch, it should always get latest code from the Development branch.
Can someone help me on this?
After you merge Feature 1 to DEV you then have to merge DEV to feature 2 branch
We use TFS for our version control system in AX 2012, and have been experimenting with branching for the purpose of better controlling what goes into testing and release environments.
Microsoft gives the example scenario here of a main branch, then two child branches Dev/Release.
How do you actually do this in AX? Merging in Visual Studio with XPO exports isn't the same as merging traditional source files.
Do you configure TFS parameters inside of AX to point to a Dev branch, then check-in code? Then at some point change the TFS parameters to the Release branch and re-check-in code?
What's the practical use of it?
We are using TFS integration with AX 2012 this classical way, with Main, Dev and Release branches.
TFS integration is setup in AX. Then merge at check-in if there was concurrent modifications is done by TFS. If needed, TFS merge popup if it Can't resolve the conflit itself. The merge between branches is dons in TFS too.
You must not change on the Fly the branch your are setup on. One major thing in AX TFS integration is to keep consistency between AX modelstore and local repository. When you will check an object out or get its latest version, it won't compare the TFS server version with the current in AX but in the local repository.
If you need to reaffect one dev environment to another branch, you'll have to set the modelstore and the repository local at the same level on the targeted branch and change the setup in AX.
The main purpose is to have in Dev branch all the on going developments and run nightbuilds to validate technically the current version. The Main branch is the one you will merge into validated developments to create release candidates to pus to tests and UATs. The Release branch is to have the exact version of your Live environment in order to make hotfixes without the ongoing evolution in Dev and Main branches.
We use an isolated branch per developer and a MAIN branch where we all merge to. And then extra branches for TEST and PROD for code promotion of changes.
MAIN branch has a build process that compiles it recurrently so we are sure the merged changes are still solid, and TEST branch has a build process that deploys to a test AOS for consultants. PROD branch is only for historic reasons, no build or AOS is related with this code.
There are several/many questions regarding TFS branching strategy, but I am haven't been able to come up with a strategy that fits with my scenario. My TFS project consists of a single solution that contains a Web Project, a Business Layer Project, and a Data Layer Project. The project is a portal of reports. Reports are largely isolated in subfolders within the project. There are however some features across the entire project such as session management. Over a given period of time, the workflow may occur as follows:
Stable snapshot of code.
Development of Report A begins.
Development of Report B begins.
The project with the inclusion of Report A needs to be pushed to our qa environment.
The project with the inclusion of Report A and Report B needs to be pushed to our qa environment.
The project with only the inclusion of Report B needs to be pushed to our prod environment.
So basically, each report is on a completely independent timetable. I need to be able to independently publish a branch of code to our different environments. Currently, we don't have branching - we just don't add a link to a new feature if the project gets published when a report isn't ready but is included in the project. Not the best scenario.
My initial go at a branching strategy was to have Main sit between the QA and prod environments, basically as just a container to merge before branching to a production branch for a production publish. Each report would be developed on a branch from main. For both our test and qa environments, a branch from main would be created and the appropriate development branch(es) would be merged into this "proposed updates" branch. This doesn't work though because I am merging development/feature branches into a branch that isn't the parent branch. I can't have Main at this level because a Report may be in development for weeks while another may be on a timetable that has it developed and pushed through the process to production in only a few days. My "proposed update" branches for test and qa need to be able to be independently created from a merging of only the appropriate dev branch(es).
My only experience with branching/merging is a main+dev pair of branches, so I'm very out of my element here. How can I setup my branching in such a way that I am able to merge features in on independent timetables without getting stuck and code being published to an environment before it is ready?
If it matters, we are on TFS 2008 right now and hope to go to TFS 2010 soon. This is an immediate need to get going on our current TFS 2008 server though.
I'm not exactly clear on everything; reading comprehension and all.
As I understand it, your current process is Dev -> Test -> QA -> Production. Devs work on code, push it to an environment where they can test on it. Once satisfied, they push it to QA, and when code passes it moves into production.
In addition, you have several "teams" (1 or more devs) that must work on separate reports, each of which must eventually be moved through the above process into Production. Teams may be working on code that is distinct from all others, or teams may find they cannot move their code forward until other teams reach stability.
If I were in charge of branching for this solution, I would recommend the following.
First, create a Production branch. This branch only contains production code. Only your QA team touches this branch.
Next, create a QA branch. This branch is also maintained solely by QA teams. They manually merge test code into this branch, run their quality assurance tests, then merge with Production. Every time they merge with Production, or test code is accepted into QA, a label is applied to the branch. If test code fails, the branch is reverted back to the prior label.
Development teams manage their own branches. They are created by branching from QA at the latest label. This assures they are working with the latest approved code. Developers work with and test on this branch. If teams have a dependency on each other, they should work on the same branch, unless it becomes clear that creating secondary branches from their shared Dev branch would be easier. Once a Dev branch meets the milestones set for the developers, QA should be informed that the branch is ready for merging with QA for testing.
Alternatively, depending on how complex development is, you might even consider uniting the QA and Production branches. Often, it is a simple matter to add a label to a branch to indicate a stable, production worthy build. It also keeps the branching strategy as simple as possible, which is always a good thing.
I think you should look at the Branching Guidance put together by the VS ALM Rangers.
http://tfsbranchingguideiii.codeplex.com/
This should alswer all of your questions. You are looking at quite an advanced branch plan. I also have some good practical guidance on my blog. I know that I am talking about Scrum teams, but it is basicaly Feature branching based on the Guidance.
http://blog.hinshelwood.com/archive/2010/04/14/guidance-a-branching-strategy-for-scrum-teams.aspx
If you get a chance please vote over
at the new "Visual Studio ALM"
StackExchange over in Area51 as we are
trying to setup a place dedicated to
answering these questions with the
Visual Studio ALM MVP's and Visual
Studio ALM Rangers on hand to answer
your questions.
http://area51.stackexchange.com/proposals/15894/visual-studio-alm
[I know this question is old but this may help others that come across this question]
Most "branch per feature" teams use one "main" branch and break away from the branch per environment approach. Environment releases can be handled by clearly labeling each environmental release on the MAIN branch.
The QA release is the result of merging all features/issue branches considered fully tested and ready for QA into MAIN. As bugs are found, new bug branches are branched off of MAIN, which are fixed and merged back to MAIN. When all QA releases are deemed ready for production, a PROD build is made from MAIN. In short MAIN is the one source of truth for code.
If you need to work ahead, an integration-test branch (TEST) can be used to determine what features are "production ready," but feature/issue branches should be merged to MAIN on a case-by-case basis, rather than in bulk from the TEST branch.
Hotfixes can be branched from the PROD label, then fixed, tested and merged back to MAIN for a new PROD release.
I'm going to refer you to a great video on Branch per Feature. It focuses on GIT, but the strategies do not depend on GIT and can be used just as effectively on TFS SCC: https://youtu.be/9SZ7kSQ2424
I am working with a small development shop that consists of a group of 5 developers and 1 QA person. We are using TFS and need to get more sophisticated on how we use this tool.
Currently the development team checks in their code each evening. A nightly build runs and pushes the output out on a network share. Our QA person uses this build for testing the next day. Sometimes the build off the trunk codebase has issues/bugs that hinder the QA process, and it hasn’t been a giant issue in the past, but we now want to get to a state where we have our QA person testing on a stable QA build.
So I believe we need to create a branch (call it QA), and the developers will continue to develop off the trunk, but the QA person will use builds created from code in the QA branch.
Seems simple enough, but we have started doing code reviews as well. So we have another desire in that only code that has been code reviewed can be promoted to the QA branch. Each developer works off a TFS item, and when they check in a changeset, they do it against a TFS item which creates a link between a checked in code file and a TFS item. Eventually the TFS item becomes complete and ready for code review. All code attached to the TFS item is reviewed. How can the versions of these files get promoted to the QA branch?
In the QA branch, if a bug is found, we want to fix it in the QA branch and have the changes migrated back to the trunk. I believe TFS has a way to automatically do this doesn’t it?
Long story short, we want to get to a build and CM environment that I believe is pretty standard, but we are unaware of how to make this happen with TFS. Given our situation above, can someone point out a book or website(s) that would address our specific needs? We would like to make this happen without having to get too deep in CM theory or TFS.
I very much appreciate any and all suggestions!
Thanks,
John
You might want to take a gander at the resources on CodePlex. There are different strategies laid out for how you might want to build your branching model.