We have 3 environments: dev, test, and staging.
I want to check in and out of TFS. When we make changes, I want to promote the code to the dev web server. Next I want to promote the changes to test, then to staging. Would it be possible to do this with Team Foundation Server?
Why on earth are people suggesting branching? You branch for different features or static branches for release snapshots.
Surely the differences between these environments are configuration items/files and settings within these. All you need to do is get your deployment and release management process in order.
Create appropriate MSBuild tasks and use TFSBuild (Continuous Integration) to call these to take care of outputting the correct config files for the Environment/Configuration you are building. You can trivially add another MSBuild target that deals with the appropriate deployment to the respective target environments.
You can manually checkout the code from each branch, make your changes subsequently to each branch, and checkin. Very carefully.
Much better is to have these 3 environments be branches of each other. (Typically you start with dev, and branch to the other 2 in turn). Then you can use the Merge functionality to merge (for example) your dev changesets directly to test, etc. At this point your Test modules (that need to be changed to match dev) are checked out, with the changes. Then simply commit the changes. Then repeat for staging and rinse. This is the suggested methodology for this common scenerio.
Two important notes:
Even though TFS if very server-centric (compared to SVN, for example), this merging functionality happens on the client. You need to have each branch mapped to your machine. After the Merge process is completed, you'll have uncommitted changes in the target branch until you check in.
In Microsoft's vision and in the example I give here, these branches are permanent. This was a change from my previous practice using SVN, where whole branches were created/promoted/retired all the time. In the TFS way, you create the Test branch and it remains, indefinately, the Test branch. It's never promoted; its changes are merged elsewhere.
Building is a separate action. You need to set up a separate build for each situation, though of course once you set up the first one the other two will be trivial. After your merge to staging, you'll then run the staging build. (From Team Explorer or in the Build menu). TFS is a bit heavy but once it is set up it does handle this situation very well, easy for a distributed team to merge and build quickly (with automated build tests, etc.).
Yes, this is possible, but you must manually check them in from one branch to another.
Related
I think that it's good idea to build artifact and then deploy it across all environment, test, preprod, prod.
But according to Gitflow we use "release" branches for tests and we merge it to main, develop and delete release branch. So we have "release" artifact and we test it, but as I understand we deploy to prod artifact from tagged main branch. And for me it's strange.
What could be the objective reasons of this?
main <=> prod
The reason for this is simple, however, the usual name of the main branch is master. One needs to have an easy way to refer back to whatever prod contains, because, in the case of hotfixes, you want to branch out from prod, because the issue is reproducible there. It is another matter that there is usually a branch for hotfixes as well.
release branches
Basically, you may have many different things that are being developed at the same time. You probably want to create well-separated partitions of problem-spaces to define your tasks, each such partition would represent a release. So, if you are optimizing some business logic on the one hand and you are polishing the UI on the other hand, then you not necessarily know which one will be released first, so you will have some named branches for those. Having "release" branches is a convention for this. Now, when you are deploying a release to prod, you can merge master into your release branch and perform automatic and/or manual tests. When this is successful, your release branch is merged into your master branch.
Deleting a release branch
Once the work represented by a release branch is successfully completed, it makes sense to remove it after it was merged to avoid wasting storage space on things that are unlikely to change (because they were accepted). Note that if a problem arises with a release later on, you can always checkout the commit hash of the tagged commit that represents the release merge in order to see whether the problem you have seen was already manifesting when the release branch was released.
We are using visualstudio.com TFS to store the source code. We have DEV, STG and PROD branches. now I want to automate build and release to IIS server.
But it looks like to me that TFS compiles the code from the branch where I commit to, and that's the only build, after that I can install the same binary on all the servers.
But it doesn't seem to be ok, because what if we find a bug on the live code, so we need to fix it, but we already have new code in DEV, and we don't want to revert, and install the old code with the fix on the dev server?
What I think we should do is to merge the code from DEV to STG, from STG to PROD, but I couldn't find any module for that. And it looks strange, I would be surprised if I am the only person whats to do this, especially because it is doable with Jenkins.
thanks
I typically discourage automating merging of code between branches; merging should be a deliberate action. When someone expresses that desire, it's usually a sign of a problem with the branching model and deployment model they're using.
Code promotion branching (where you have one branch that corresponds to each environment, as in the scenario you described) is a bad practice because it encourages you to build different sets of binaries for each environment. You build something for a lower environment, test it, validate it, then totally disregard that testing and rebuild from source. That should terrify you, especially for production branches -- you have no idea if what you just built is going to work properly.
Current thinking is to minimize the number of branches you have, and instead isolate in-progress work behind feature toggles so that features that aren't ready for production can simply be disabled, but still allow deployments to take place. With sufficiently mature feature toggling practices and testing practices in place, you can actually eliminate branching entirely and work out of a single branch, promoting binaries to production whenever your automated and manual QA process deems the version they're testing is good.
Assuming you're using TFVC, if you want to maintain a code promotion branching strategy, then you'll need to maintain multiple builds and releases, one for each branch/environment. Typically, in this kind of scenario, I'd eliminate the stage branch entirely. Anything that goes to the Dev branch is built and deployed to Dev. Anything that goes into the Prod branch is built and follows a deployment pipeline from staging->production. Hotfixes can go directly into the prod branch and be merged backwards. There are tons of strategies for branching; you'll need to read up on the subject and design a branching and release strategy that works best for your team.
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
We have been using TFS 2010 to manage work items and sprints for a while now and have recently added on a dedicated QA person. What I need to be able to do is to either create a build definition that I can run on a scheduled basis (Tuesdays at 9pm for instance) that will only build and/or deploy the Work Items that are in a State of "ReadyToDeploy". Or a way to get a list of files to push based on the TFS API.
My end goal is to have a way to automate the release process so that only the items that have passed QA are sent to our staging environment weekly. Then the customer or QA can approve that the items work in staging which is a mirror of production, and another process or build definition will deploy those items which will be in a different state.
I have modified the work items and work flows to accomplish the different states, but I am having an issue getting either a build of just the fixes or a list of all the files to push based on the state of the work item.
I am open to any ideas or solutions for this, the alternative is that I have to manage the list of files and manually push files every week and I am trying to get away from that.
Thanks,
Edit: The way we have it setup now, is that each developer has their own branch and own website, our software is server based and has to be run on a particular server. Our Trunk is linked to the main dev website. This is where QA initially does their testing to move an item to the ready to deploy status. When a dev is ready for QA they check in their changes in their branch and merge into the trunk. The builds are created off of the trunk at the moment. On our deployment nights I open up the trunk website in VS and do a publish then take those files compared against a list the developers have given me and ftp the compiled files to our production server.
I could be wrong, but I am not aware of a way to tell a build to avoid certain changesets based on the state of an attached work item.
I think the only way you could achieve this would be to create a Release branch and perform a daily merge of changesets that are in the "ReadyToDeploy" state. When you merge, you are able to cherry pick changesets, but they must be contiguous. This means that you would have to perform multiple merges to get the Release branch into the appropriate condition.
We have operated something similar for many years and it works well for us. Many people will tell you that it's bad practice, and it probably is, but that is for you to decide.
As for automating this for a build, I don't think it would be a trivial job. The hardest part will be the merge. You might think that there will be no conflicts as it is a one-way merge, but having done this for a number of years, I can tell you that conflicts do arise.
Step By Step Explanation
Create a branch off the trunk called release
When you want to do a deploy, merge from the trunk into release, but only cherry pick the ReadyToDeploy changesets. This may take several merges as the changesets must be contiguous.
Fire off a build / deploy of the release branch.
Repeat steps 2 - 3 as your release schedule allows.
You could do something automatic, it would require an extensive bit of coding. It would also require a branching strategy so that, Dev, Staging, and Production all come from their own branches.
Set up a process that uses the TFS API to scan for items in that state
Use API to Traverse Items to get check ins attached
Use API to Get latest of source and target branch
Use API to Merge by change set (identified in #2) (this is non trivial, have to handle lots of cases, but merging should all be 1 way with no conflicts, so doable)
Use API to Check In
Kick off Compile Build
If Compile Build Successful kick off Publish Build
To the best of my knowledge there is a major issue with this approach. Say you have two changesets: # 1 and 2. Both of them containing modification for the same file. Now changeset #2 contains its own changes plus changes from #1.
If you decide to pull in changeset 2 and skip #1 guess what's gonna happen. You are going to suck in changes from #1. This is obviously a problem.
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