While we are waiting for Microsoft-hosted agents support (build without a VM) to be released, we have to have a dedicated build VM that generally sits there and does nothing. To save costs we can setup a schedule to turn it on and off, however, you have to align your build schedule with it, and it does not make a lot of sense if you do not have active development and do changes once in a while.
Here is a quick and dirty workaround. You can get Azure Virtual Machine Manager extension from visual studio marketplace.
It adds one task to stop or start a VM.
Now we need to modify standard build definition and add new task to start build VM.
You cannot add it to existing agent job, because this one is self-hosted and requires VM to be up and running, catch 22! So, add another agent job:
Bring it forward and add Azure VM task:
Now your pipeline should look like this:
And to make it work we need one more change. In the build options it demands DynamicsSDK and obviously new agent won’t have it and will fail, so I simply removed DynamicsSDK from the list, that’s why I call this quick and dirty!
To stop a VM after the build I put Azure VM task in the very beginning of the release pipeline that is automatically triggered after a successful build.
Using this neat extension, we can automatically start a VM before a build starts and then immediately turn it off after the build. I deliberately put stop task in the release pipeline, so it won’t stop VM if build fails and I can investigate or quickly rerun it without waiting for VM startup. Obviously, one day we will get ability to use MS hosted agent but meanwhile it may help you to save some $$.