We have several assemblies that we share over all our projects. Since last year we use NuSpec files to create packages and share them all in a internal feed. The packaging is done as part of the build process (TFS 2015). Versioning is set to automatic, use date and time. The build is a CI build and triggered when merging from the Development branch to the CI branch.
When one wants to use the packages, one has to enable "include prelease" in the NuGet Package Manager to get these packages. This is ok, for time while a package is not completely tested, but ready to release.
Question
What I am looking for is a straight forward way now, to promote such packages, once they've been created and tested, to a release version, leaving the original Major.Minor.Revision but removing the date portion of the prelease version and share that new version in a - ideally the same - feed.
Related
We are considering a move to Azure DevOPS/TFS and we have built a prototype workflow which seems to work well.
The only outstanding thing from our current CI process to replicate is the triggering of builds based on nuget package updates.
Our build pipeline is a tree, where some libraries which generate nuget packages generated at the top of the tree are used as dependencies in other libraries downstream.
Using team city one of our build steps inspects the dependencies of a solution, identifies the topmost level dependencies and adds them as nuget build triggers ensuring that the next time a successful build of a dependency occurs the downstream library is triggered as well.
How can that be replicated in Azure Dev Ops?
I think you might be after something like NuKeeper:
NuKeeper automates the routine task of discovering and applying NuGet
package updates.
NuKeeper will compare the NuGet packages used in your solution to the
latest versions available on NuGet.org, and:
List available NuGet package updates on .NET code on the local file
system or on a GitHub server.
Apply NuGet package updates to .NET code
on the local file system.
Make pull requests containing updates to
code on a GitHub server.
Image stolen from Shayne Boyer's blog.
I am new to the world of scripting with TFS2015. I created a script that builds all of the projects within my solution (it is a rather large solution) and puts it out in a shared folder (where each project has its own subfolder).
I would like to create a separate script for each project that simply copies the bin folder from the shared and pastes it out on my Test environment. I rarely need to deploy everything, so the idea is one build...multiple deploys.
However, when I run my deploy script using the Copy Files step it is doing another build. Although it copies the files that I expect, it is after a full build that creates the folder structure for the build.
Am I able to make the Copy Files step NOT do a Build?
Here is the steps that my script is curently doing:
As you can see, there is only one step (Copy Files) but it still does the Get sources and copies everything into a new folder on the build box like so (where the number keeps incrementing up with each run of the script):
I just want to copy the files from the Source to the Target and not do a build or Get Sources.
It looks like you're still on TFS 2015 RTM or Update 1. Which is already pretty old technology if you compare it to the lifetime of the new build system which was introduced with this version.
TFS 2015 update 2 has introduced a similar system to the Build pipelines to orchestrate Releases. This doesn't require you to map any workspaces or git repositories and can act on the artefacts of your builds or simply on the contents of file shares.
It makes sense that a Build has to build something and in order to build something, it has to get the things to build. If you're actually not building something, then you're probably deploying or releasing or packaging something else. Hence the distinction between Build and Release pipelines.
TFS 2017+ has an option to disable the syncing of sources. Primarily to allow people to get the sources themselves in creative ways (e.g. a custom powershell script that invokes git.exe).
My primary advice would be to upgrade to TFS 2018 update 3 or at least TFS 2017 update 3.1, worst case TFS 2015 update 4.1. The fact that versions older than update 2015.4.1 have a known XSS scripting security bug may be reason enough to convince your organisation to perform this update.
Barring that option you're left with one solution:
Link your build definition either to a git repository with only a single commit (If I remember correctly the 2015 agent still crashes when syncing an empty Git repo) or link it to a TFVC repository and set the workspace settings to cloak everything. This essentially causes the build to sync an empty folder, which it can cache, before calling your powershell script.
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.
I have two separate solutions in TFS 2015. We'll call them Solution1 and Solution2. The build for Solution1 creates an assembly which is required by Solution2. I'm not sure of the best way to handle this dependency in TFS.
Possible scenarios could include.
Each time Solution1 builds successfully it copies the new assembly to Solution2 which in turn triggers a build of Solution2 (is this possible in TFS? And if so, how?)
Each build of Solutiuon2 pulls the latest version of the assembly from Solution1
How have other people handled dependencies between TFS projects?
You should package the output of Solution 1 as a Nuget package and publish it to a Nuget repository. You can use a Network Share, MyGet, VSTS, or TFS 2017 as a Package Repo.
Your second solution can then take a dependantsy on that Nuget Package and you choose when to update.
If you want to update the packages automatically you can call something prior to Solution 2 build, like the pre-build step mentioned in comments.
As it was explained in the other answer you can manage it with NuGet deployment. That is the really clear and fancy way.
Another way might be, if you use the same output folder for both solutions, and
you always build Solution1 first.
The third way can be that you always deploy your Solution1 to a specific location which can be referenced by Solution2. It is logically similar to the NuGet version, however you do not rely on that (but this dependency in "normal" cases is IMHO acceptable).
Your actual choose can depend on the environment and on your constraints.
I'm new to version control systems and have been tasked with revamping our company's version control (small system right now). We have library files that will get updated, but we also need to support older versions of these libraries for different generations of our product. Part of my task is to set up an automated unit testing system that will do nightly checkouts, if newer code has been checked in since the last test run.
You will likely need to keep multiple branches of your libraries in source control, one for each version that will be supported/changed in the future. Each of these branches should have a build definition created to build the code and then run the unit tests against the code. The builds can be setup to run in
CI mode which will build on every checkin
Gated checkin mode (my personal favorite) which won't commit the checkin until the build and test run completes successfully.