Git into VSO and using Build vNext to pipeline into Azure deployment slots.
Building from VSO and deploying to Azure
Create your solutions in VS
Note that I just created a solution in Visual Studio and I have not checked it anywhere, but to a local GIT Repo on my system that is not yet connected to any Team Project. Next is we want to G(e)it it into VSO.
Create Git Rep on VSO and clone your code into it.
Go to your VSO account and create a Team Project if you do not have one and choose Git as your REPO. IF you already have a Git REPO in VSO you can push into that as well. Now to push the code into Git we are going to use CLI to push to GIT.
Install the Git Command line tools
Establish REMOTE REPO
Come to your Visual Studio Team Explorer and establish the GTI Repo you created above in VSO as your remote repo to your local Git Repo on your workstation. See below on how to do this.
Checkin in from the Local Git Repo you created which at this point is NOT in any way connected to any remote REPO.
Go to a Visual Studio Command prompt and using full path to Git PUSH you code into the remote Repo. (Note that the Git path does not get added to Visual Studio command prompt, so you have to full-path into it as shown below).
See your code in VSO
Having got code into the Git Repo now check out features (a) Build vNext and (b) RM deployment to Azure Environment (Windows and Linux) and (c) ARMing them
Build vNext
Create a DEV branch in your local REPO
resulting in >>>>>
From now on we work in DEV branch and push to master when required.
Set up a build definition on VSO for this project and enable CI on DEV branch
Now go to VSO and create a Build definition. A few key screen shots are shown below.
Choose Repository to be DEV branch
Enable CI Trigger
Save your Build vNext definition.
Now you have to set up things in VSO, time to get some action in your code. Get back into your favorite editor (VS, or VS Code, Eclipse or whatever - notepad) and Edit Code and Trigger CI by committing into the remote REPO. When you commit to repo, note that your first commit will be local to the repo. Then you need to SYNC to remote (ie VSO) so that it triggers the CI on VSO.
Once you do that, you should be able to see your build getting kicked off in VSO's hosted build controller (by default) and getting deployed into the SLOT you wanted it to go.
Note that you can also have your own build machine pointing to your VSO and build off there. This is explained separately below in another section.
Deploy to Azure Web Site from your CI build
Add your (OR connect your) Azure Subscription as Service feeding from VSO
Go to the gear icon on your project from VSO and then go to Services and click on Azure as shown below and enlist your Azure subscription.
Add Azure-PublishAzureDeployment.ps1 PowerShell and set the script arguments
(Note that this is a kind of workaround OR another way to do it) If on the other hand you set up your VS project as a proper Azure based Web Site project, meaning used the OOB Azure Web Template that came in Visual Studio, then all parameters would be fed correctly and your web site would get deployed. You don’t have to go this route.
Download the PowerShell from the below URL.
Add it into your SRC tree and refer to this script in the Script Path as shown below. For those of you who use Release Manager, and do DSC based deployments - this part of checking your deployment script into SRC code will sound familiar. It also drives home the point your deployment should be treated as CODE and should be checked in and version controlled. Essentially we checked in the deployment script and will then use this deployment script in the actual deployment, when we add the deployment step as shown below. Note that to logically reach to the deployment step, we first have to (a) Build the solution, (b) Test the solution etc.,. in order to get to the deployment. IF you see below these have been made into discrete individual steps that you add based on what you need by clicking on "Add Build Step". In the Earlier XAML builds these were all entwined in a workflow.
Now since PowerShell is an option to execute, it provides a lot of flexibility if you wanted to add things which you think are not in the default set of "Steps" provided OOB. And you could then refer to these PowerShell Scripts (which you should of course check in along with your SRC code) in the PowerShell Step as shown below by the ScriptPath component.
Script Arguments:
-WebSiteName "MyTestWebSiteinAzure" -Package "$(build.stagingDirectory)\BldAndRMvNxt.zip" -ConnectedServiceName "000000000-000000000-0000-0000000000" $AdditionalArguments "-Slot QA"
Once you had set this correctly, you should see your Code changes and checkins being propagated and deployed straight to your Azure Web Site.
Using RM and Deploying to Pipelines
The current version of RM (ie RM on premises) as of today cannot access the build definitions created on VSO, though they could take the XAML builds. However with RM capabilities that are being surfaced in the online version (Build video - https://channel9.msdn.com/Events/Build/2015/3-649 ) this will not be a limitation. That opens up a richer set of deployment options for building complex DEV, QA, PROD Release pipelines.
Agent Choices when using VSO
When building with VSO you have a plethora of Agent choices. The most obvious is the hosted one provided by VSO, so everything happens under the covers for you.
You also have a choice of building your own Build Agents.
For this you have to download the Agent binaries as shown above, along with the config file from VSO portal and then you could deploy to your servers and configure to communicate with your VSO as shown below. It will ask for your account in the popup to authenticate to the VSO.
I set the agent to run interactively just for grins to see what it spews out as I use it. This would be useful in those situations you want to debug.
Once you have set this up, you should see your agent in the pool you added it to. In my case the default group as shown below.
Once you do this you can now start building on your own agent instead of the hosted build agents, if you are concerned about billing/consumption.