Month: June 2017

DevelopmentDevOps

Visual Studio Team Services Build to the Rescue

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:

image

I then clicked on the ASP.NET (PREVIEW) featured template:

image

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:

image

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.

Enjoy!

References

TeamCity

Visual Studio Team Services

Azure Storage Explorer

Octopus Deploy

AzureDevelopment

How to: Build and deploy an Angular app to Azure using Visual Studio Team Services

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:

  1. You will be required to have an active Visual Studio Team Services account. If you don’t have one you can signup for free here.
  2. You will also need to have an active Azure subscription. If you don’t have one you can signup for a free trial here.

Now that we have met the requirements, let’s get started.

Create a new build definition

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.

image

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.

image

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:

image

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:

image

Now that we have our source code wired up, you’re ready to start defining your build tasks.

Defining your build process 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):

image

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:

image

This will be the configuration for our npm install task:

image

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:

image

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:

image

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:

  1. Select you Azure subscription
  2. Select your App Service name
  3. Select the package or folder you wish to deploy

image

Here is a review of the build tasks we created above:

image

Queue a new build

Once we have our build process defined we can kick off a new build by clicking on the Queue button on the top toolbar:

image

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:

image

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:

image

Viewing your build process

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:

image

Voila, our build is now finished:

image

Visual Studio Team Services build can also be configured to send out an email when builds succeed and/or fail:

image 

Now that I have a successful build, lets browse and take a look at our deployed Angular app: http://blog-angular-deployment.azurewebsites.net/ .

Wrap up

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.

Enjoy!

References

Azure free trial

Visual Studio Team Services

Build and release tasks

Hosted agents

Angular

Angular CLI

Uncategorized

#CognitiveServices – How to create audio files for Custom Speech Service (#CRIS)

El Bruno

Hello!

A few days ago I was asked about an easy way to create audio files to be used as datasets in Custom Speech Service (CRIS). As I mentioned in a previous post, the audio files must have special features, so it is important to create them correctly.

Note: the files are WAVs files, mono and another pair of details makes it not easy to create them in a single step.

Although there are several ways to create these files, this is the one I use and it works.

  • To record the audio I use an app that comes by default in Windows: Voice Recorder

Clipboard02

  • I guess I don’t need to explain how the app works. Just press the microphone button. Nor do we expect many options in the Settings section.

Clipboard03

  • Once we have recorded a session, we can access the list of recordings. If we see the record path…

View original post 186 more words