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
Related
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.
Is it possible to merge the development branch into the staging branch, when the development branch successfully builds?
Assuming your goal is to have your code deploy to a staging environment then I would suggest that you have the wrong promotion model there. Code promotion models, like you describe above, are pretty antagonistic to continuous anything. Either you just want continuous integration, or you want to go all the way to continuous delivery you are doing it wrong. Switch from code promotion to binary promotion.
You should build a single version of your application, from a single branch, and promote that through various states of quality. Added bonus is any tests run against these binaries are valid passed in any environment. Recompile and you have to reset your test plan.
http://nakedalm.com/create-release-management-pipeline-professional-developers/
It pretty east technically to change to a binary model. Any difficulty will be political and cultural within your organisation. It is however very much a fight worth having.
You could customize your build, so it does this using the tf.exe command-line client (or the TFS API). I would use a powershell script, that in-turn used the tf.exe tool to do a merge + check-in to the desired branch.
However, the problem is this only works if there are no conflicts. If there are conflicts, you won't be able to automatically resolve them in order to complete the merge.
You can configure a build definition to your staging branch in "Gated Checkin mode" trigger.
When you commit code to staging branch a build must be run successfully before you code is uploaded to source control.
You can find more information about "Gated Checkin" in MSDN:
https://msdn.microsoft.com/en-us/library/dd787631.aspx
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).
I've the following structure on TFS:
$Base
- $Dev Branch 1
- $Integration Branch 2
I would like to merge the changes on Dev Branch 1 to Integration Branch 2 so that build guys can kickoff Hudson build of this Integration Branch.
I'm using Visual Studio 2008 Team, and when I try to merch Dev Branch1 I can only see Base on Target Branch drop down.
Could anyone please advise how and if it's possible to merge between Dev and Integration branches above.
Thanks
There are a couple of ways to do this but neither are that great. For the first method you will need to install the TFS 2010 power tools
Use a shelve set. Start the merge from dev to base, resolve any conflicts. Do not check in the merge, instead shelve the changes. Then from the command line use tfpt unshelve "my shelve set" /migrate /source:$/teamProject/dev /target:$/teamProject/integration. This will migrate the shelved changes to the integration branch without having to commit the changes to the base branch.
Perform a baseless merge between dev and integration. You can do this by using the command tf merge $/teamProject/dev $/teamProject/integration /baseless /recursive once the baseless merge has established a branching relationship then you can do further merges through the UI. Be warned though that a baseless merge won't know about any files or folders that have been renamed or moved so you will need to make sure you take this in to account.
Personally I'd go for option 1 if it's a one time thing. If it's going to be something you think you'll need to do regularly then I'd do the baseless merge when all 3 branches are in sync I.e. just after you've merged from dev to base to integration. This should minimise any issues with the baseless merge.
You might also want to take a look at your branching strategy so that you don't need to perform complex merging operations very often. If you use an integration branch then it should have a direct relationship with any branches you need to integrate. Check out the ALM rangers branching guidance.
You can only merge to where the branch was created from. You would have to merge from Dev to Base and then again from Base to Integration.
If you want to merge from Dev to Integration directly then your Integration branch should be created as a branch from Dev not Base.
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