I’ve been putting it off, but in prepping for SQL Bits demos, I decided this was a good time to just upgrade my original build and release tasks on VSTS from v1 to v2 for the Redgate tasks.
The first step was to go into the marketplace and find the new tasks. If you browse the marketplace (click the shopping bag icon in the upper right of VSTS) and search for “redgate”, you’ll see the tasks.
I picked the two on the right, the build and release tasks v2. The v1 tasks aren’t in the marketplace, but if you’ve added them to your account, they’re still there and they work in your build and release pipelines.
Once I installed them, they appear in my list of extensions.
Now I can edit my pipelines.
I’ve got a release pipeline that looks like this. Note that these are the v1 plugins, because there’s no v2 on the name.
My plan is to upgrade these to the new extensions, however, there are lots of settings. If you look to the right for any of the tasks, for example the Create task, there are lots of boxes to fill in.
This is expected as if I were doing this manually, I’d expect to have along set of commands or switches to programs or parameters, that I’d need to pass in to a process. After all, the mechanics of implementing CI or CD aren’t hard, but they do have lots of moving parts.
My first step in making this easier is to add a new task. To do that, I click on the “Add tasks” button above. This will default me to the set of tasks for me particular function, in this case, release (deploy). I scroll down to see the v2 tasks.
Here I see the v1 and v2 tasks because they’re both listed in my set of tasks because I’ve installed both into my account. In this case, I’ll pick the “2” version of this task.
Once this is added, I need to configure the task. In my case, the easiest way to do this was to click on the v1, copy the contents of a text box, and then click on the v2 task and paste the values in there.
Once I had done this, I have both tasks listed. For this particular pipeline, I had actually added a new Agent Phase, separating my tasks out. There wasn’t any great benefit to this, though I can then just delete one whole phase and all the tasks in it (once things are working).
After copying all the settings from one to the other, and checking that v2 was configured the same, I was ready to test. I first went to each of the v1 tasks and unchecked the “enabled” box. This means those tasks won’t run, but they’re still in the definition.
After that, I created a release and deployed it. Not every deployment worked. My first ones did, but when I tried to hit the production environment (the far right), it failed early on. This list is from newest to oldest, so I had a few things to work out here.
As you can see, this isn’t necessarily a simple, easy process. In my case, the v2 tasks have some additional path items, and I had to sort those, I also had firewall issues to production as I was traveling between the tests, which meant forgetting, and then needing, to reset the firewall rules.
However, it’s all good now.
I would encourage you to upgrade your DLM v1 tasks to v2. There are a few bug fixes, some of the deprecated cmdlets are removed, and these work slightly better. I know have pathing options to separate my environments on the agent and can easily see the code being run.
I’ll talk about my test procedure for upgrading in the next post, because I think trying to do too much at once is how I’ve gotten into trouble and created stress for myself in the past. Now I have a better idea.
Voice of the DBA 