How to set up CI/CD on TFS--importing dependencies?

Question

I'm setting up CI on my project, and I'm having trouble getting some DLLs installed. The set up is as follows: repo sits on a TFSGIT 2015 server. I set up a build server (agent) on a VM. When the code gets checked in, the build server builds, runs the tests, etc. The builds are failing because some internal packages/DLLs (that are sitting on a different TFS 2010 server) cannot be found.

My question is: what's the best way to solve this? I guess a crude approach is to simply add the DLLs to the repo, but I was wondering if there is a pre-build step where I can import the DLLs from the TFS 2010 server. Would a simple power shell script do it?

I'm unfamiliar with the microsoft stack so any guidance/suggestions would be appreciated. Thanks.

Answer 1

There are a couple of ways to handle this, you could:

1. Create a NUGET package of the functionality you are using and host this internally. The bonus here is that you are doing things in an appropriate build manner from a CICD perspective and maintaining appropriate versioning so that you can, in the future, ensure that you can rebuild an exact instance of a version. When you do a NUGET RESTORE step, you can simply add the arguments: -source

   • In VSTS/TFS2017 you can add your own NUGET feed.
   • You can create one simply with code. Hanselman: Creating your own Nuget Feed
   • You can use a 3rd party host.

2. (Assuming your remote TFS isn't storing versioned builds of these) Use a build step to copy those files out of the remote TFS server into a versioning system, applying the version details as meta-data. Again, the concern here is being able to fully ensure that you can roll-back effectively at a given time.

3. Use Powershell to grab a specific build-version artifact from your TFS server, here is an example script to grab the latest build. If your DLL projects utilize builds, you can use this - this should be trivial to modify to grab a specific build. I would do this via some build variables, personally. The biggest thing to note here is the "DropLocation", that will be the file drop for the Artifact. Mike Poulson: Get last known good build via Powershell

4. Directly use a Powershell script to copy the data from the other TFS in a build script. At the minimum, saving this in your artifact will suffice to roll-back at a minimum, but I like to ensure that I can build backwards as well especially with larger projects. Just in case something drastic happens with your artifact storage. This answer can help you: Copy files from bfs version control to directory There are also powershell tools to help with this.

There are probably countless ways to resolve this, but my suggestion would be to take a step back and architect it the right way; in this instance, you want to make sure that if a remote build is occurring and creating depend artifacts, that you are managing them appropriately and capturing them in relation to a specific build. That's why I still suggest utilizing your own NUGET feeds.