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.
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
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
In the company I work for we have a Release branch from which we publish versions to production.
I want to prevent a situation where someone checks in changes made in that branch directly without the changes were synced from the development branch.
Is there a way where I could set the Release branch to allow check-ins for change-sets which are of "Merge" type only?
By this I could ensure the change-set was originated from the development branch and achieve my goal in addition to preventing non synced code between production and development branches.
You cannot fully restrict a branch to allow merges only. But there is a checkin-policy made by a Microsoft MVP which you can configure. Combined with the checkin-policy from the TFS Power Tools you can configure it to a speficic folder. The configuration process is explained on teh download page.
Does TFS support local commits?
In other words: Can I
modify the code,
make a local commit (without sharing these changes with others),
test my modifications and
if my changes didn't break anything, do a global commit (thereafter my changes are available to other developers)
in TFS 2012?
If it doesn't, are there any workarounds, which allow this functionality?
No it doesn't support this, however it does have a couple of alternatives you can use instead.
1) Branches - All developers work on their own branch then merge to trunk/main when they're happy with their changes.
2) Shelveset - developers shelve any change they don't want to commit yet. This lets you undo your change, or pass it to another developer on the team without losing the change or checking into the main branch
3) Gated Checkins + Unit/Automated tests. Any time a developer checks in, TFS Automatically shelves the changes and runs the tfs build + any associated tests (unit or automated). If everything succeeds then it is checked in. I don't believe this supports manual tests.
or a mix of all of the above.
TFS does not support this by itself.
However! Microsoft released Git integration with TFS. Brian Harry blogged about this: Announcing Git Integration with TFS a couple of weeks ago.
Using this setup you can use Git for your local commits and then commit it to Team Foundation Server.
Not for the on premise version of TFS (yet), but as of January 2013 Microsoft's hosted Team Foundation Service has Git support, which obviously supports local commits.
http://tfs.visualstudio.com/en-us/news/2013-jan-30.aspx#git%20support
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