Last month I migrated our TFS collection to VSTS using Microsoft’s Database Import Service and migration guide. To be frank, it was a long process and it took a lot of going back and forth to make sure I fully understood the guide which is a PDF that is 58 pages long. The guide comes with several checklists and things you need to check and prep before your migration.
Update: Unlimited private pipelines are now free for Build!!
Microsoft caused a lot of confusion when they announced that you will need to pay to run private build agents, since this was free in TFS. Why should we have to pay to use our own server resources to run a build agent?!? You can see the outcry in the reviews on the Marketplace: 1.7/5 stars: https://marketplace.visualstudio.com/items?itemName=ms.build-release-private-pipelines#review-details
Once I fully understood how and why the billing is setup this way, I wasn’t as frustrated.
When I first got started with Octopus Deploy I would setup projects to have one long deploy process that ran steps in serial. Each step would wait until finished before another one would start. Deploy times got longer and longer, so I set out to find a way to cut down deploy times.
This last year our team made the decision to move from Team Foundation Version Control (TFVC) to Git.
Currently the TFS/VSTS build system has a pretty big bottleneck: tasks run in serial. For build steps that run PowerShell, I’ve implemented runspaces to run processes in parallel (Invoke-Parallel is amazing). However, that only works for one build step. The rest have to wait until it’s finished.
Enter Queue Build(s) Task. This extension sounds pretty simple, right? Queue a build as part of a build…. But it has potential to do much more. It has the ability to use configurations (JSON) to pass variables from the build that’s queuing other builds, including system variables (source branch name, build id, build name, etc.).
When Microsoft announced Task Groups in TFS and VSTS, I couldn’t think of a practical use for them. When creating build definitions I always try to reduce the number of overall definitions by using prompted variables when possible, this way the user can modify the variable when queuing a build rather than duplicating a definition that has the same steps. Of course this doesn’t work well for things like working directory which warrant a separate build definition. This is where I found Task Groups shine.