[0:00:45] – Demo
- Build and deploy Java to Azure Functions
- Deploy a Docker container app to Azure Kubernetes Service
- Deploy a web app to Azure App Services
- Azure DevOps overview
- Create a free account (Azure)
Source: Channel 9
[0:00:45] – Demo
Source: Channel 9
So this week Visual Studio Team Services build and release saved me and my team.
At our company we have configured an on premise continuous integration server along with build agents using TeamCity which is a product from JetBrains. TeamCity Professional is actually a free application that allows you to run 3 build agents. The only cost is the associated hardware and Windows licensing. I fell in love with TeamCity years ago when I set it up at our company and it’s been a very stable and a versatile CI server since. However this week I ran into some issues with our TeamCity server and the fact that it was on premise only added to the problem. Let me explain.
Our build server physical infrastructure is actually located offsite from our office (along with other dev/qa servers), so when I say on premise I really means its dedicated hardware that we own and not up in the cloud. The situation we ran into is that our TeamCity server didn’t restart properly and was unavailable by remote access by the ITOPS team, this meant someone had to go to the offsite location and reboot the server. Now you might be wondering, why don’t you have a backup…a good question and something I’ll be looking into.
What made matters worse is that we we’re nearing the end of a regression cycle and we wanted to deploy later this week. So having our build server drop off the grid was just bad timing and it meant DEV and QA were in a holding pattern while we waited for our build server to be brought back up and hopefully it was ok and not corrupted or worse.
While we waited for our build server to be restarted I started thinking about worse case scenarios like what if our build server is dead and we need to rebuild or restore from a backup (and what do you know it was out of date). None of these options can be done quickly and they require unplanned resources from the ITOPS team and myself.
Having already explored Visual Studio Team Services (VSTS) build and release services for my personal development and that of our Live .NET logging tool ReflectInsight, I knew I could easily and quickly get one of our applications setup in that continuous integration pipeline. You will actually be shocked at how quickly I got things going.
Our current build process typically builds the solution, runs unit tests, creates a nuget package and then finally publishes the nuget package to an internal nuget repository that is part of TeamCity. We then have an automated deployment service called Octopus Deploy that picks up this package and can then deploy to any of our QA and/or production systems. Since our TeamCity server is offline, I would need to publish the nuget package to another destination for the time being. I decided to create an Azure Storage account and then copy the nuget package there. I could then pull the nuget package down and manually upload to our Octopus Deploy server.
To get started I headed over to my Visual Studio Team Services account I had setup with my MSDN subscription and I then created a new project to contain my builds. I then clicked on the Build & Release tab and then clicked on the New button to create a new build definition:
I then clicked on the ASP.NET (PREVIEW) featured template:
I then configured the Get sources task to point to our GitHub repository and then I added in the last two steps for generating a NuGet package and to copy the generated NuGet package to an Azure Storage account:
I wont go into detail for each of these build tasks as their pretty straight forward, but after I had everything setup and tested, I looked at the clock and it was under 15 min from start to finish. That is something I could never have done in our existing on premise build infrastructure and it now looks like I have my backup solution.
One of the nice things about using the hosted agent in VSTS is that it’s located in Azure and its a service that is managed by the Azure team. This means I spend more time focusing on developing my applications and less time worrying about managing the associated build infrastructure and what happens if a server goes down, performing backups, restores and that all hands on deck feeling when your infrastructure goes down at the worse possible time.
This post will guide you on how to build an Angular 4 app using Visual Studio Team Services and then deploy it to an Azure App Service instance.
So let’s review what we’ll need before we begin:
Now that we have met the requirements, let’s get started.
We will start by signing into your Visual Studio Team Services account and then navigating to the Build & Release tab from the top navigation links to create a build. From here we will click on the New button to define a new build definition.
Next you will choose a template to use for your build. There are a lot of build templates so take a look at what’s available and choose what is most appropriate for your needs. If you don’t see what you want, you can always choose the empty template which is what I’m going to do now and then add the necessary build tasks that make sense for you.
After selecting the empty template you will want to name your build definition, connect your source code repository (Github, Visual Studio Team Services, other) and then start adding build tasks:
Click on the Get sources link on the left side to wire up your source code for the build. In this demo I’m connecting to my personal Github repository:
Now that we have our source code wired up, you’re ready to start defining your build tasks.
Now that we have our build definition configured to our source repository, it’s time to start adding build process tasks. To do this we click on the Add Task button from the left which will then present a listing of available build tasks (some of which are in preview):
In this post I want to build an Angular app, so I will need to use an npm build task. Using the search box I will type in npm and the listing will then filter out to only show me any npm build tasks. At this time there is one, so I will click on it and then the Add button to add it to my build process:
This will be the configuration for our npm install task:
Next we will need to add another npm build task for running the Angular CLI build command ng build. This will be the configuration for our npm run task:
At this point our build is installing all necessary npm packages and then running an npm command to build the Angular app. Once the app is built, I like to archive the build artifacts in a ZIP file. This will be our configuration for our archive files build task:
Finally we will deploy our app to an Azure App Service instance. To do this you will want to have your Azure App Service already pre-configured. You can checkout this post for details on creating an Azure App Service.
This will be our configuration for our Azure App Service Deployment build task. There are 3 settings you need to set:
Here is a review of the build tasks we created above:
Once we have our build process defined we can kick off a new build by clicking on the Queue button on the top toolbar:
This will being up the queue build modal where you can define the agent queue to use, the branch to build or a specific commit along with defining build variables, etc. I will select the Hosted agent queue and my master branch. I will then click on the Queue button to initiate the build:
For more information on the differences between the hosted agents, checkout this link for further details.
You should now notice that your build is now queued:
You can click on your build at anytime and see detailed output for what is happening during the build process along with view and/or download detailed log files:
Voila, our build is now finished:
Visual Studio Team Services build can also be configured to send out an email when builds succeed and/or fail:
Now that I have a successful build, lets browse and take a look at our deployed Angular app: http://blog-angular-deployment.azurewebsites.net/ .
I hope this post helps your build and deploy your Angular apps to Azure. As you can see it’s very straight forward to setup and requires no build infrastructure on your end to make it happen.
If you're not having fun, you're doing it wrong.
.NET, Azure, and Office dev
Informaly tackling serious topics
Intelligent Apps for Pilots
My personal blog about everything technical
coding facts and opinions
Avanade CoE - Technical Architect | Data Platform MVP
Exploring the world of Azure, IoT and other interesting topics
where learning never ends...
Practical Coding Tutorial
A blog about Microsoft Azure
Christian Nagel about C#, ASP.NET Core, UWP, Xamarin, Azure, and more
Cloud Computing & DevOps Tips & Tricks with Hammad Aslam.
Stefan Wick on UWP and the Microsoft Developer Platform
Software Research, Development, Testing, and Education