I am using TFS on-premise, but this question pertains to the team services release management online too.
I am working on a new setup to use the new Release Management tools. I have a Main line in TFS source control, branched into a Dev branch. All work is done and checked in on the Dev branch. We manually merge code from the Dev branch back to the Main branch. When we do this, we have a auto build in TFS to download the Main branch repository and do a build of the source. I have a release management environment setup to take this build of the Main and deploy it to a staging environment, and then to take the same bits and deploy to a production environment.
My question pertains to the process of releases and bug fixes. Normally we would use a release branch per release, and then apply bug fixes to that code and release from that branch. I don't know the best practices for handling this situation in Release Management. I still want to use the RM configuration I have setup to perform the release of these bug fixes, because I need to put the bits through the same QA process and have auditing/records, and also use it to deploy the bug fix release to staging/production.
I can't find any guidance on MS documentation about how to best do this through Release Management.
You could create a new release definition to deploy application to production environment. For pervious release definition, it is used to deploy application to staging environment to do test and verify.
So, if bugs be fixed, check into Dev branch and merge into Main branch to trigger build and release (deploy to staging environment), after a major release is ok and approved, trigger another release manually to deploy to production environment.
Related
I have web applications that we build using build scripts and deploy as the last step of those build scripts, if everything builds and unit tests pass. We deploy to staging area.
With the new Release management functionality in TFS, Should I move the Deploy task from the build definition to the Release area? The Release Definition seems to only be able to copy files versus a build script can update an application running in IIS.
I honestly at this point do not see the need for the Release Management in TFS.
The Release Management is used to be an independent tool of TFS.
It has been integrated into Azure Pipelines and Team Foundation Server (TFS)as web-based version in TFS 2015 Update 2 and above or Azure Pipelines.
Release Management not only be able to copy files versus a build script but also as a Continuous Delivery (CD). It is a process by which code is built, tested, and deployed to one or more test and production environments. Deploying and testing in multiple environments drives quality.
CI(build) systems produce the deployable artifacts including infrastructure and apps. Automated release processes consume these artifacts to release new versions and fixes to existing systems. Monitoring and alerting systems run continually to drive visibility into the entire CD process. The Release service in TFS helps you set up and manage CD for your applications.
As for the difference on Release Management vs deploy task at the end of build pipeline, you could also take a look at this similar question: TFS Release Management vs build deploy task at the end
Can anyone explain to me (or point me to a link) how TFS 2015 works with Release Management?
We have been using Release Management for about 6 months and recently started doing some research on TFS 2015. From what I understand, TFS 2015 V2 has integrated with RM.
Since my question is so broad, let me narrow it down to a few specific questions.
Do I still need to manage my templates and release paths in the RM client or is there a way of managing them from the TFS web site? I have read about how to set up a release from TFS, but its always about scheduling and linking artifacts. It seems similar to setting up a CI build in Jenkins. The client works well for me, but I am under the impression that I wont need it anymore.
Do I have to manually kick off an RM release from a TFS Release. When we use Jenkins, we have some post build steps that include starting an RM Release from command line. When I am setting up build tasks in TFS, I only see 2 options for deployment that arent relate to Azure: run command line or run a Powershell script. Do I need to kick off the RM release using a powershell or command line script, or is there a better way of telling TFS to kick off an RM release.
It is probably obvious that I am not clear on how TFS and RM integrate together, so feel free to chastise me and point me to some reading material. I have read the documentation on MSDN but even the screenshots in their docs dont look like my TFS interface, so maybe we didnt install it correctly?
The new Release hub in the TFS/VSTS web portal is a complete, ground-up rewrite of the Release experience. It has no relation to or integration with the old Release Management Server product. They are totally separate. The new Release hub is based on the idea of you writing your own deployment scripts in whatever manner works for you and using the Release hub to invoke the deployment scripts and track their progress through your environment pipeline.
You'll want to migrate off of Release Management Server, as it's no longer receiving feature updates, only bugfixes. For migration, you can use the ALM Rangers' migration utility (disclosure: I worked on this project).
For kicking off existing Release Management Server releases as part of your build process, I wrote some build tasks for the new TFS build system that you can grab on Github. They won't work in Jenkins, but you should be able to use them as a reference point. If you are using TFS build, you can import them using the TFS CLI.
I have a Visual Studio solution with one SSRS project, two SSIS projects, one SSAS project and one SQL Server project. I'm using TFS2013 Update 4.
I'd like to deploy this solution using TFS Release Management in two environments. First environment should be "populated" after the developer's check-in and in the second environment the projects should be deployed only in the next night (during the day the environment is used by the testers and a new deployment can affect their data).
It's possible to achieve this with TFS Release Manager 2013.4?
Update 1:
A single gated check-in build is taking too much time and that's why in this moment I have gated check-in builds separate for each project in order to keep the developer's waiting time to minimum.
Update 2:
The current setup is with five gated check-in builds that are building and deploying each project to the first environment and one nightly build that is building and deploying to the second environment the entire solution.
Add an additional "collector" build, that you automatically queue from the others whose purpose is to collect artifacts and be the reference for Release Manager.
In other words, say you have five CI builds, one for each project named CI1 to CI5. In each CI post-test script you run a similar command
TFSBuild start /collection:%TF_BUILD_COLLECTIONURI% /buildDefinition:Collector /queue /msBuildArguments:CIDrop=%TF_BUILD_DROPLOCATION%
to queue the Collector build.
This latter collects the artifacts from the parent build and the last know good artifacts of the remaining CI builds and copies them to its drop location.
Now you can use Release Manager as usual on this Collector build.
I'm looking at using TeamCity 7.1 as our build server, and I am trying to figure out if it is possible to do what I want.
Our TFS branching looks like this
MyProject
tags
1.0.0.0
1.1.0.0
2.0.0.0
trunk
So our process is to work in the trunk, and when we reach a point where we want to deploy, then we create a branch with that code. In the above example, version 2.0.0.0 is in production, and the trunk has further changes made to it. So if I need to fix a bug in production, then I will fix it in the 2.0.0.0 branch.
I am able to set up a build that checks out the trunk, runs tests, etc., without any problems, and it can be triggered by checkins to the trunk. But I would like to also monitor all the version specific branches, so that when I check in a bugfix in the 2.0.0.0 branch, then a build is triggered, and all my tests are run.
It seems that some of the VCS options have had a new feature added to support this called "branch specification" (https://tom.cabanski.com/2012/11/19/teamcity-7-1-branch-builds-rock/) but that is not available on a TFS VCS root.
Is it possible to do this without creating a separate build configuration for each of my version branches? Or is there a way to manually launch a build of a specific branch, by using my existing build configuration for the trunk?
Since "feature branches" are not supported for TFS in TeamCity (only for Git and Mercurial at this time), creating separate build configurations is the best way to build separate branches. Actually, even for Git and Mercurial creating separate build configurations for long-lived version branches (as opposed to feature branches which come and go) is recommended.
I am not sure how branches are handled in TFS, but if you use tags, I believe there is no way to build off a TFS tag in TeamCity (TW-7370).
We're using TFS to follow a pretty standard agile build process:
Nightly builds from latest source code
Build to staging server every 2 weeks
Build to production server every 4 weeks
I've got 1 and 2 set up in TFS and working great. However, I'm struggling a little with #3. If I just set up a "normal" build, it will pull the most recent source code and use that to push to the production server. But what I really want is to move the code from step #2 to the production server since it's already been vetted by the QA team.
I thought about doing a custom build template that uses XCopy or something along those lines, but then the issue is how to update the configuration strings.
I was following this article, which seems to be exaclty what I want, http://www.asp.net/web-forms/tutorials/deployment/configuring-team-foundation-server-for-web-deployment/deploying-a-specific-build, but it is not working.
How do you all accomplish this?
So this is a slightly easier way to achieve 3. if you have achieved 2.
Let your production build definition stay as it is. However to compile the same changeset that was used to compile your staging build in step 2 (which has now been vetted by QA), when you queue a prod build then on the parameters tab expand the Advanced section and find the "Get Version" property as shown below.
In here you can specify the same TFS changeset that was used to build your build in step 2. Assuming this changeset is number 84, you would write (exactly)
C84
if you compile labels then for a label named - "For build xyz" you specify
LFor build xyz
Note that "C" and "L" above are intentional.
Hope this helps.
We have a different branch for production and code only gets merged into the production branch after passing Q&A.
That allows us to apply hot-fixes to production code with changes directly on the production branch (those will eventually get reverse integrated into main then dev) while development continues on the development branches.
Once code in the development branches are ready for Q&A, it is merged into the Main trunk.
CI and nightly builds are done on the development branches - the difference being nightly builds having more comprehensive automated tests