The Challenge
We have an on-prem application (RM) that cannot communicate with VSO
Our code must stay in VSO
We need to give RM access to Build Definitions that are tied to our VSO source
Attempted Solution
Install TFS locally to host build definitions only
Have those build definitions pull from VSO
Problem
It looks like we can't use a VSO project directory in the Source Control Folder mapping
Is there a workaround?
Your best bet is to start migrating to the new Release Management service in VSTS, since the existing Release Management Server application is rapidly being deprecated. There are tools available to help ease the pain of migration.
You could also use RM Server in non-integrated mode -- nothing would be tied to build definitions, and you'd have to specify the path to the build drop manually when queuing the release. It can still be automated via the ReleaseManagementBuild.exe utility in the Release Management client folder, it would just take a bit more effort to build it out.
You could also build a custom build process template to pull the code from VSTS and build it, but again, that's investing a lot of effort in RM server.
[Full disclosure: I am a contributor to the migration tool linked above]
Related
Related to TFS 2017 release management artifact files from version control
I'm asking a new question because I believe I have an edge case the answers don't directly address and I don't want to derail that OP. Specifically, how do I allow an independent, offsite team building required supporting scripts in a separate TFS Team Project supply their scripts as an artifact in the Release definition of a separate TFS Team Project? The separate team projects are built by independent customers and we are not allowed to append content to their source control. Further, updates to the scripts must automatically spread to all Release definitions using them on the TFS.
We have about 40 team projects in TFS all running on different schedules. A separate operations team handles all build and release management tasks in TFS.
Because of the constant bouncing between team projects and because ops also wanted to use the version control and work item tracking features in TFS, we created a separate team project for them to store scripts, installers, and license files. These are referenced in other projects' RM tasks for automatic installation/execution. There is also a separate version control folder tree for tracking project specific scripts - like this:
Common
Applications
App1
App2
...
App43
This makes it significantly easier for them to manage their scripts and associate them with work items themselves without having to shuffle across all the other team projects. The dev teams do not have access to the ops project.
However, when linking a version control artifact in RM from their project, it will only bind to the root and appears to copy the entirety of the version control structure to the agent, even though most of this content is not relevant to the app being deployed.
Is there a way to add specific, not all, folders from their project in version control as artifacts to a release definition in a separate project? We have our QA release start the process to production and it pulls in the artifacts from the ops project and the project being released. All subsequent releases reuse the artifacts that succeeded in the QA build instead of going back to the server for new versions of the artifacts.
Build definitions don't let us pick workspace paths outside of the team project so I don't see a way to pull in their scripts in a build step, either.
Is there a way to do this? How are other organizations handling this issue?
No.
The same answer I provided in the other answer applies here: Don't. Publish them as NuGet packages or as separate build artifacts; a release definition can have multiple artifacts linked to it.
I appreciate Daniel's answer and I believe what he is stating is best practice. However, I believe I found a more direct technical answer to my question through the use of additional repositories.
Release Management allows you to reference Git repos and branches independently, like I had originally hoped to do with folders under the TFVC repo already in a separate project. In this way, we configured the TFVC repo to handle large binaries (installers), license files, etc. which we version and put in a Team Project Nuget feed for reference from RM. To address the folder issue, we created separate Git repos for our operations team project in the same TFS project. Like this:
Binaries (TFVC-based repo)
Git Repositories
CommonDeploymentScripts
Environment Scripts
App1 Scripts
App2 Scripts
etc.
This way TFS RM from any other project can be configured to pull in any one or multiple of these repos as artifacts for use by the agents, bringing down only those scripts that were placed in them.
Also, the ops team doesn't have to cross reference app-specific scripts while bouncing around in a bunch of independent team projects. Note: Daniel is right when he says app-specific stuff should really be versioned and stored with the app project itself. However, some environments may not yet have that luxury so this can fill that need.
RM lets you reference branches under a single Git repo as well so this might be overkill. However, we didn't like the idea of branches under a repo not really having any business ever being merged up into the master - felt like too much room for error.
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'm currently setting up continuous integration using TFS/Visual Studio Team Services (was VS Online), and I'm using the Team Foundation Build 2015 tasks. So not the XAML builds.
I'm using it to build a Xamarin Android project, but that's pretty irreverent I guess,
The process should be like this:
After a check-in:
TFS should download the sources
TFS should increment the version number within AndroidManifest.xml
I've managed to do this by making a PowerShell script for this.
After the AndroidManifest.xml file is modified, it should be committed back into the TFS repository
Then the rest, build deploy into hockeyapp etc
The first steps are all configured, but I'm struggling with the commit part. How do I get TFS to commit the file? I don't really see any task suitable for it. I've tried using the Copy and Publish Build Artifacts Utility - But that did not seem to work, and I'm not even sure if that's the right utility
I'm using the default hosted build agent btw. Any help would be appreciated
Warning
I do want to point out that checking in changes as part of the build can lead to some features of VSTS/TFS not working. Association of work items to the checkin, sources and symbol generation, tractability from changes to build to release and integration with Test Manager, remote debugging, will likely not yield the expected results because the Changeset/commit recorded in te build may not match the actual sources. This may lead to unexpected funny behavior.
Also, if any new changes have already been committed/checked-in after the build has started, the version number may be updated in Source Control for code that was not actually released under that version.
So: First of all, it's considered a bad practice to change the sources from the build process.
Alternatives
There are better ways of doing it, one is to use the build version (Build_BuildNumber or Build_BuildID variables). Alternatively you an use a task like GitVersion to generate the semantic version based on the branch and tag in your git repository. That way your build will generate the correct version number and will increment the revision in case the same sources are built multiple times.
I understand, but I still want to check in my code as part of the build
If these things don't work for you and you still want to check in the changes as part of the build, you can either use the TFVC Build Tasks if you're using TFVC or use the Git Build Tools to add the remote to the local repository and then use the git commandline tools to commit and push the changes back to the repository.
These extensions require TFS Update 2 to install. But you can push the individual build tasks using the tfx commandlien tool. For the TFVC tasks the process is explained here.
On mac
On the mac it's going to be harder since you're using TFVC. My TFVC tasks leverage the TFS Client Object Model and Powershell to communicate to the TFS Server. The tf.exe tool doesn't even work on windows when you're in the context of a build, which is why I need to call into the VersionControlServer object directly. Given I'm dependent on these technologies, the tasks won't run on a Mac or Linux agent.
You could try to see whether the Team explorer Everywhere X-platform commandline works from the build agent (using a shell script). I have no way to test this on an actual Mac.
Given the cross platform nature of your project I'd recommend to move to Git, it integrates into XCode and Android Studio, making it easier to do a native UI or build on top of native libraries.
Alternative 2
You could setup a build which does the required changes to the code and then checks in the modified code. Then have a (CI) build run the Android and the Mac builds using the modified code.
I am trying to grasp Release Management vNext and dsc configuration 'management' (how to manage DSC configuration files). In the 'Deploy Using PS/DSC' dialog box while editing a vNext Release Template
Why is PSScriptPath relative?
Does it really mean, that I somehow have to get my scripts I want to use relative to my current drop folder? What is the best way to do achieve this? I want to be able to do:
Have a separate git repository for configuration files
Reuse configuration files across different projects
I've read a promising article Packaging DSC configurations for Visual Studio / TFS Release Management vNext but it seems to be out dated and some kind of hack from my point of view.
How does Microsoft want us to use this? How to achieve reusable configurations in a separate repository?
Thank you
Use a submodule to your separate configuration repository, then ensure the submodule is initialized during the build. You can then copy the configuration scripts to the build drop folder as part of your build script.
The reasoning is that your deployment scripts will evolve over time, and that evolution should be something that is captured. If you ever need to redeploy an old version of your software, that old version shouldn't be deployed using new scripts -- it should be deployed using the same version it used initially.
I have created a lightly customized TFS build process template and also appropriate TFS build definition. It builds fine on the TFS build server.
Is there any way I can allow developers to reuse the same build process XAML and definition to do full builds on their local machines? Maybe there is some utility which can be run with TFS build process XAML files?
I really would like to avoid maintaining a separate copy of the build script for full local rebuilds.
The build templates can only be run by the TFS build service. Without installing that on each developers machine, that might not be the best idea.
An alternative is to setup a share on the developments machine and grant access to the TFS Build account (the one that TFSBuildServiceHost.exe runs on the server as). Then the developer can Queue a build and get the Server to Drop the files onto their machine.
The downside to this is you need a lot of builds to be run on the Agents.