>> Believe it or not, VSTS is not just for .NET projects.
In fact, Go Developers can get a lot of
value from using VSTS for DevOps.
Thanks to its large set of
services which are free for individuals and small teams.
Jessica Deen is here to show us
how Go Developers can get the most out of
Azure and VSTS today on Azure Friday.
Welcome, everybody, to another episode of Azure Friday.
I'm Erik St. Martin, and today
with me I have Jessica Deen,
who is going to talk to us about all the wonders of
VSTS and features that are useful to Go Developers.
>> Absolutely. By the way, hi,
Scott's friends, it's so great to be here. So, yes, Erik.
Today, I'm going to talk about VSTS and how,
as a Go Developer,
you can take your code that is
hosted out on GitHub or somewhere else,
and you can bring that over into VSTS and ultimately use
VSTS as a CICD pipeline
to get your project out into Azure.
>> So, for our Go friends who may
not be familiar with VSTS,
like just generically speaking, what is VSTS?
>> So, VSTS stands for
Visual Studio Team Services, and it's
a tool or a set of tools that you
can use to implement DevOps practices.
You can actually use it to host code.
So, if you do have code hosted on GitHub,
great, you can use an external repository.
If you like to import it into VSTS,
we do also give you
free private repos on an unlimited amount,
and then you can also set up things like
Kanban boards and work items,
you can get pretty elaborate with VSTS.
But for today, what we're going to do is we're going to
walk through a project I've pre-created.
It's actually a very well-known project
in the Go open source community.
I've downloaded it quite a bit, it's called Crochunter.
It was developed by Lachie Evanson,
who actually works on the Helm team,
and this is an app where you can live out
your dreams of hunting crocodiles.
>> Well, it says hunting crocodiles, not hunting gophers?
>> Exactly, because then that would be a problem for Go.
So, I'm going to click on my "Crochunter" project,
and I actually have the code file of
this living out into GitHub,
and we're going to walk through how
I am going to take this Go project.
I'm going to build and push a Docker image,
I'm going to push it up to an Azure Container Registry,
and then I'm ultimately going to release it out into
a Kubernetes cluster I have in Azure,
but I'm going to do it all from within VSTS.
So first off here, after I clicked into my project,
you'll notice on the left-hand side of my navigation,
I only have a handful of buttons.
I am using the new UI and they'll
be links probably at the end of this
where people can go see where to
get these features and how to turn them on.
However, I also have
hidden certain tasks that aren't relevant to me.
So, I mention that you could
also use code as hosted as part of VSTS.
You can set up work items and
sprints and backlogs and track stuff.
That's not relevant for my project today,
so I actually set up where
to hide that in my project settings.
>> So, they would just appear here?
>> They would just appear here. You'd see
code, you'd see work,
you'd see test, you'd see
all these features that you hear
as part of DevOps practices.
But from the first part that we care about,
since my code is on GitHub,
I just want to build and release
code that I have somewhere else.
So, I'm going to hit my "Build and release",
and it's going to take me right into
my summary page where I can
see my CI that I've
already previously configured and fired off.
I can see the history of any of the times
it was successful and any of the times that it failed.
If I click into the most recent build,
I can see the progression,
including any of the logs.
So, let's take a look at how I set this up,
how I set up my continuous integration
or my build within VSTS.
You have a few different areas.
You have tasks, you have variables, triggers,
all these different features really give you rich powers.
But to get started is actually a lot simpler,
all you really need is tasks.
So, under the "Build" process,
you see that I set a name
and then I have what's called an "Agent queue".
So, an "Agent queue" is actually a set
of systems that VSTS gives you,
they're hosted, we take care of everything,
and they're setup to build or release your pipelines.
So, they run the tasks
that you later define in your phases.
>> Now, can you run this on your own infrastructure?
>> You can, you absolutely can.
So down here, you would also have
"Private" and you can set up
your own agents on whatever build servers you have,
and the more you get into this kind of configuration,
I do recommend setting up
your own build servers because
our hosted servers are stateless.
So, each time you build
a Docker image and has tuple layers,
those aren't going to be cache
for the next subsequent build.
If you use a private agent, obviously they will.
So, the next step you'll see is "Get sources".
I can see a wide variety of where I can get my code from.
I have GitHub selected and I've already
authorized my GitHub account and repository.
The next is just the set of tasks that I'm going to run.
These are all tasks that I would run manually,
but VSTS is going to automate for me.
So, by default, you can
see that the first task I have is Docker.
So, if I wanted to go search for tasks,
I would simply click the "Plus",
which will take me to the marketplace,
and I can search for things like Docker
or Helm and add tasks accordingly.
I hover over, hit "Add", and I'm done.
But for today, I'm just going to
show you the tasks that I've already added.
So, here's a build image task,
I've specified that I'm going to
use an Azure Container Registry.
Though if I had a Container Registry somewhere else,
I could easily select that.
I select the "Subscription",
where the Container Registry lives.
I select the "Container Registry",
and then I choose the "Action".
The next few steps is what I'm going to tell
the Dockerfile to do or the Docker task to do.
So I'm going to tell it where my Dockerfile is,
I can use the ellipsis to manually search
my directory and find the Dockerfile,
or I can use a wildcard search that'll
recursively search my directory
and select my "Dockerfile".
The next thing I have is "Build arguments".
So this particular Docker image,
which is building a Go application,
actually, if I go over to Visual Studio Code,
you'll see here on line 17 and line five,
I have an argument and environment
variable that's going to capture my VCS
or my GIT_SHA reference and bake it into my Docker image.
So, VSTS allows me to pass variables from
the pipeline and pull them over into
my Dockerfile and build the image accordingly.
You can also take a quick look at my Go application,
which again is a super simple HTP website
just a static application.
So, switch back over to my VSTS image.
So, the next step is where I just choose an image name.
I choose if I have any image tags, and that's about it.
The final steps are pretty straightforward
because "Push an Image" is just the same.
I fill in the same information for my "Container
Registry" and my "Azure subscription".
The only difference is the "Action" is pushing image.
So, I can see that right here.
The next steps are all Helm tasks.
So, I'm going to actually take
this image after it's built,
and then I have charts in
the same directory that's going to
package up my Helm charts
and hand that off for my release.
So, you can see that since it is a hosted agent,
I have to prep my system up.
So, I add in an "Install Helm" task,
which is going to install Helm,
it's going to initialize Helm
on the hosted agent locally,
and then it's going to actually run
the "Helm package" command,
where again you can see where I'm connecting
my Kubernetes cluster this time,
not a Container Registry.
I choose the "Subscription",
I choose the "Resource group",
I choose the "Cluster",
and then under "Command",
I choose the "Package" command.
So all this is under phase is just task runners.
All the tasks that I'd manually do,
I have VSTS do.
>> Now, if you were running on your own agents,
you wouldn't necessarily need all of the installing Helm.
This is just because that was basically
our clean slate every time your agent comes up.
>> Exactly. Because this is a hosted agent,
so I don't have anything persistent or configured
that knows my authentication in my Kubernetes cluster.
The final step is a drop step where I'm actually going to
publish the TAR file
that I created from the package stop.
I'm going to publish it out into
something that my release can go out and grab,
and so we will be able to see that in the release stage.
So, I'm going to go ahead and hit "Queue",
and we'll actually kick off a build so you can see this.
I can double check and make sure I do want
to run this on a hosted Linux preview,
which I do, and I'll simply hit "Queue".
After this fires off,
it's going to go off and run all these tasks for me,
and you can watch as it completes.
But the next cool thing is not
only can I watch and see as it completes,
I also have a continuous deployment trigger setup
that's going to automatically fire off my release.
So, it creates this domino effect of a pipeline.
So, we're just going to wait
for the request to be queued,
and then afterwards it starts running through the tasks.
>> Now, can you
have this triggered based off of the Git command,
for instance, so that
this pipeline starts running
the second you commit something?
>> You absolutely can. So, this is actually
already listening to a GitHub change,
so I could go over and make a change here.
I wanted to show that you can also manually kick it
off and you can do things after you've set up your tasks.
But if you have your code on GitHub or you have
it in a VSTS Git repository,
either way when you do a Git push,
it will fire off your build,
it'll also fire off tasks that you have,
and then it'll ultimately hand-off to release
based on if it passed the build.
>> Excellent.
>> So, you can see as this goes
through and builds an image.
While it's building, we're going to go
ahead and take a look at our releases,
so we can see how our released pipeline
actually looks pretty identical to our build pipeline.
So, we'll see that I have a pipeline that I've already
built, I'll click into it,
and just like on how build,
I can see the success rate,
I can see visibility into
the success or failures of my releases.
If I click on the ellipsis,
I can edit and see what
tasks I'm going to tell the release to run.
The first thing is, is that
I'm going to tell it to grab the artifacts,
the stuff that I published from the drop folder,
it's going to publish over in
my CI where I want to pull artifacts.
That's going to have a continuous deployment trigger,
which is setup right here and it is enabled,
that's going to kick off
the release into this environment.
Again, just like on how my build where I
set up an agent phase and I set up a queue,
I told this to run
these tasks again on a hosted Linux preview.
Then, just like on the build, I'm installing Helm,
I'm initializing it, and then
this time rather than running a "Package" command,
I'm actually running an "Upgrade" command.
This is unique because aside
from setting up my Kubernetes cluster,
which I don't have to do again,
I just click the
"Dropdowns" and select whatever the "Resource group" is.
In this particular command,
I'm able to specify a separate "Namespace" so I can make
sure you implement best practices
and keep things isolated.
I can use the "Upgrade" command with the "File path",
but then even more importantly,
I can actually use "Arguments",
where I can set really important information
that's going to override my values file,
so that I can set things like my pull secrets and
my private registry information over to my ACR.
So, I have this automatically,
dynamically creating a pull secret
for this deployment and it's going to grab.
You can notice right here, I'm going to hover,
it's going to grab a password
from my Azure Container Registry.
I can set that password in
an encrypted format under "Variables",
and I can set that value right here with
the lock that will make sure that it's not plain text.
So, once that kicks off,
it'll end up deploying.
If we click back into "Releases", by now,
we should see that the release has kicked off,
if not complete it, which it has.
Build 14 was actually the latest release.
So, if I click into
the "Croc Hunter" application and I refresh it,
I can see my commit ID
from VSTS, and we'll just zoom in here.
I can see the release is my ch9go-vsts,
and I can also see the host name,
which is the pod that
this particular rendering is running on.
Now, this is really powerful but it's not
as powerful as if you're just getting started.
Microsoft and Azure actually has something that's
even more powerful that ties into VSTS.
We recently announced DevOps projects,
and even more recently,
we've also added Go support.
So, if you don't have a Kubernetes cluster on AKS or
you don't have an Azure Container Registry or you
don't even have a VSTS account and you don't want to
have to set up all these things
manually and add in all these tasks,
we can do it for you with the Go application.
So, you would get started from
your Azure portal and you click "Create a resource".
From here, you can actually scroll
down and hit "DevOps Project",
it's one of the popular items that selected.
Always cracks me up because DevOps is popular.
I love it, I was never the popular kid in school.
So, under here, you can start with a fresh application,
and we're going to give you sample code to get started.
So, we support a wide variety of languages, including,
down at the bottom, we'll see Go. So, we'll select "Go".
>> Why is it at the bottom, though?
We need to talk to somebody.
>> We need to talk to somebody, we
need to talk about placement.
Also, I will say I have zoomed in,
so certain things kind of got moved around.
However, now you can choose your application framework,
which will just go with a simple Go web application.
Next, we hit "Service",
and here we have a few different
services we can choose to
deploy this application to as far as infrastructure.
>> Now, this is just configuration
for where your CD pipeline is going to do.
>> Well, and this is actually configuration
for what Azure is going to set up for you.
>> Obviously, it's a provision it for you as well.
>> It will provision it and everything.
If you don't have a Kubernetes service,
it'll create your cluster,
it'll create your registry,
it'll create a VSTS account if you tell it to,
and it'll create your pipeline.
So, we'll choose "Kubernetes Service", hit "Next",
and the final step is where you can
choose to create a VSTS account,
if you want to, or you can use an existing one.
So, I'll go ahead and use an existing account,
which I'll use this time just to test.
Then for this, you can give it a project name.
So I'll just go ahead and label it ch9go-livedemo.
The final step is do
I want to name the cluster the same thing,
which I do for some simplicity,
and then you choose the "Location".
You hit "Done" and that's it.
Azure is going to create your
entire DevOps project custom-tailored
for Go to the point where you can actually go.
This is going to be the final landing page and you can
actually see your CICD pipeline,
your build information complete with deep links,
it's going to take you back over into a VSTS account.
You can see again the same kind of build process,
the same information that I had configured.
But what's even cooler is if you
click "Edit" on some of these things,
you will notice that
the tasks almost identically
matched the ones that I manually set up.
So, if we go back over to the landing page in Azure,
this is the page that you get
after it finishes replicating.
You'll see also where it'll give you a private repo
and it sets up
your sample application with an external endpoint,
and it's already configured and grabs
an HTTP routing for you.
>> Now, I saw it.
>> Yeah, and it's even configured application insights.
The even cooler thing is,
let's say you wanted to get started
with your own code today.
Under that build that it provision for you,
you can click "Get sources" and change from
VSTS over to Github
and add your own account and your own code,
and you already have a pipeline.
>> That's awesome.
>> It's incredibly powerful.
>> I mean, what are you going to do with the rest of
your day after just a lot work?
>> Drink a lot of coffee or,
for any Java developers,
install a lot of Java into my body.
It's going to be awesome. So, yeah.
I mean, pretty much that's about it.
I will say, though, that if
anybody has done this for the first time
or especially from the Go community,
please reach out and tag us.
If you deploy your first VSTS account,
that would be awesome.
I definitely want to know about that.
>> Well, thanks so much.
>> Thank you. Thank you for having
me. Thanks, Scott's friends.
>> Today, we're learning all about
continuous integration and delivery
using VSTS for your Go projects on Azure Friday.