>> On this installment of
DevOps for mobile developers, Abel joins me to talk about continuous integration
with Azure DevOps for iOS and Android. So tune in. [MUSIC] >> Welcome back everyone to another episode of DevOps
for mobile developers. I'm James Montemagno, and my best friend in
the entire world, Abel is with me. >> Still your best friend. >> Always my best friend, Abel. >> That's nice. >> So in the last episode, we showed off taking a brand new app, publishing it to GitHub, and publishing a build
from App Center. Today, we're going to
do something different. >> Yeah. >> We're going to use
your favorite tool. >> Azure DevOps. >> That's correct.
What is Azure DevOps? >> Like we all say,
it is everything you need for a software project, right? So you can create CICD Pipelines, you can track your work, so you can have repos in it, etc. But you don't have to use all the
parts inside of Azure DevOps, you can use the individual parts. >> Okay. So even though my source code that we published
to GitHub, that's okay? >> That's totally fine. If we
want to do a "Build," we can just directly link Azure
Pipelines to your GitHub Repo. >> Okay. >> So it just works seamlessly. >> Perfect. I love it. >> Yeah. >> So I figured today
maybe it would be fun is, before we set up our quick and dirty kind of smoke tasks and App Center, we're really going to
use App Center for the distribution and testing part, but I figured we would use
the other stuff inside of this, which is the "Pipelines." >> Cool. >> So what is a "Pipeline?" >> A "Pipeline" you can think about, it's like a build in
"Release Pipeline." >> Okay. >> So the idea is we want
to have a "Pipeline" that's seamless so that when
you check in your code, it'll immediately kick off a
"Build," it'll will do whatever you need for your "Build," whatever that means for the technology
that you're using, right? >> Yeah. >> When it's done, it needs to pick
up whatever builds it needs to, and deploy it into
whatever environments it needs. >> Okay. >> They have QA UAT. But I guess in the mobile, it'd be your Alpha testers, Beta testers, and eventually all
the way out even into the store. >> Oh perfect. I like that. >> Yeah. >> So "Pipelines," I guess in my mind I always thought it
was just building, but you're saying it's the build
and the deployment part. >> Yeah. It can be both. >> Okay, cool. All right.
We're going to start it. Now, I have not done anything yet. >> Okay. >> I have created
my Azure DevOps project, and I have a bunch of
other projects in here. But I don't have to do this project. >> Okay. >> So when I create a project, can you actually tell
me what it's doing? >> Sure. So the first thing
you're going to do is you're going to
create a project, right? So a project's going to encapsulate everything that you do
for a particular project. >> Okay. >> So then you can have
all of your builds. You can have all of your Repos, all of your test plans and
things like that as well. >> That can be for
not just my mobile apps, it's a project for the the sum
of everything I'm deploying? >> Absolutely. >> Okay. >> Because a lot of
times, even mobile apps, they're far more than
just the mobile app itself. You've got your back-end
code, whether it's functions. Maybe you have APIs that run on a Kubernetes clusters
or something like that. You can have databases etc. So there's a lot more to a mobile app than
just the mobile portion. Then using Azure DevOps, you create a project,
you can encapsulate all that stuff in one place. >> Okay, and I can do
public or private here? >> Correct. That's cool. >> I am, going to do public.
Why not? What could go wrong? >> What could go wrong? >> Now. >> Everybody can see what's going on. >> What are these advanced settings? There's "Version Control"
and "Work Item Process." >> All right. So when
you create a project, you automatically get a
repo with it as well. >> Oh nice. >> So you don't have to use, if you want to use GitHub,
that's perfectly fine. Then you can just
ignore that setting. But inside of Azure DevOps, there are two types of
source control systems. There's a "Centralized Version Control System" and a "Distributed." >> Okay. >> The "Distributed,"
of course, is Git. >> Yeah. >> Then the "Centralized Version Control System," I think we called it "Team Foundation Version
Control" or something like that. >> "TFVC." >> There we go. "Team
foundation version control." >> Yeah. >> So it's just what type you want. Then the process, that's, remember, you're able to track any unit of
work in your project as well. >> Got it. >> So you are able to
select the type of software development process
you want to use. Do you want to use
an "Agile Process", there's "Scrum Process", there's "CMMI Process", or even they have a "Basic Process"
now, which I'm a big fan of. >> So I should do "Basic?" >> Let's do "Basic." >> I've never done it
before. I'm very excited. >> Yeah. >> All right. >> It's streamlined, quick
journey to the point. I like it. >> I like it. All right. So
we're going to create it. This is going to scaffold all the
things that you just told me. >> Yeah. >> I can use as much or as little?
Do I have to use everything? >> No, you don't. >> Okay. >> In fact, we can actually
go in there and turn on and off services that
you want or don't want. >> Okay. So this look
kind of cool I like this. We have a summary, or these are all the things
that you just add? >> Yeah. The "Boards," the "Repos," "Pipelines," "Test
Plans", and "Artifacts." >> Okay. So I'm imagining
I've "Project Settings." Then here "Public," over
here, there's my things. >> Yeah. You can start turning on and off the services
that you want to use. >> Okay. Got it. Now,
what was the "Basic?" When I turn that from "Basic"
to "Agile," what did that do? Where would I see that
inside of my project? >> Yeah. So the "Basic" is talking
about the process template. >> Okay. >> So then if you look
in your "Boards," because "Boards" is where
you track all of your work. So my bugs, my features,
all that stuff. >> Yeah. So let's go
ahead and jump to, for instance, click on
one of the "Boards." >> Okay. >> From here, let's go ahead
and click on a "New item." So you'll notice that the type
of items that you can create, is instead of like
all the user stories. >> Oh yeah. >> Ethics and all that, it really simplifies
the process, right? So you have a task, and it's either
"To Do", "Doing", or "Done." >> I love it. >> So they just really
simplify the whole process. >> Oh, that's correct. >> Instead of needing to learn all the agile terms
or the scrum terms, you can immediately just get started. >> Yeah. I like that. This really reminds me of how
I like to build out boards of, it's almost like a
"To Do" list, right? >> Yeah. >> Actually my "To Do" list. I'm
actually doing it, I'm done, and I could probably apply a lots of other crazy things you could
do right inside of here. >> Of course you can customize this "Board" to make it
look however you want. You can add whatever
columns you want. You can add styling rules etc. You really can customize
this however you want. >> Got it. >> But the nice thing is, the base process template is
really simple and easy to use. >> Perfect. Love it. So our app already lives
inside of GitHub today. >> Cool. >> We have a few branches
that we set up previously. HelloDevOps and Master. But you're saying that I could go into "Repos" and create
repos inside of here. There's "Branches",
"Pushes" everything. >> It's just a Git repo. >> They're equal. >> So I love GitHub for
all the social programming, the type of stuff that you can do. So inside of Azure repos, it doesn't quite have all of those really cool new social
type of features. >> Yeah. >> So it just kind of depends on where you want to store your code. But ultimately, it's just a Git repo. >> Cool. I like that my
favorite feature of this, I've used Azure DevOps
for some private projects that I didn't want to
be public or social. Is that you can have multiple
repositories under a project. >> Yeah. I love that too. >> Because GitHub is like
everything is a repository. >> Yeah. >> But you don't have a Git project. >> Yeah. You can't kind
of group them together. >> Yeah. This is cool
to me. You can import. Look at that. Just give it to me. We're not going to
do it, but we could. >> Yeah. >> All right. So "Pipelines." >> Yeah. >> I click on "Pipelines."
What's happened? What are all these things, "Builds," "Releases,"
"Libraries?" Talk to me. >> So a "Pipeline," remember
is your CICD "Pipelines." You're building "Release Pipelines." So underneath your "Build" tab, that's going to be all of
your build definitions, right? So you can create a build definition
that compiles just your iOS. Or you can even make it
super complex, right? You can have one build that
builds everything for you. >> Oh good. >> So your iOS portion, your Android portion,
your backend functions. >> Okay. >> Whatever else do you need, right? >> Yeah. >> You can even track your database schema and build those as well. >> Oh cool. >> So you can have one "Build"
that does absolutely everything. That's the "Build" portion. >> Nice. >> The "Release" portion is
your "Release Pipeline." >> Got it. >> So then there you can define, okay, with the "Build," I
have all of these bits. Now, how do I deploy it out to
all of my different environments? >> Got it. >> It can be as simple as
complex as you need it to be. >> Got it. So we'll do the "Releases" later. Let's
focus on "Builds." >> Sure. >> I'm going to do a new "Pipeline." >> Okay. >> Now I'm a classic
editor type of developer. >> Okay. Nothing wrong with that. >> Can you tell me why there's YAML everywhere in my life
all of a sudden? >> All right. So there's a big trend in the industry right now
for YAML-based "Pipelines." >> Got it. >> Right. >> YAML is just a yet
another markup language, it's just a markup language. But what's really cool about
this is if you can define your pipelines inside of
YAML or in a YAML file, that file can now be stored in your source control right
alongside your source code. >> That's cool. >> So now everything
gets version together. >> Got it. >> Right. So think if
somebody forked your repo, not only do they have all of your source code, but
they have your pipeline. They have your build
definition as well. >> They can take it, they can build something like
that. That's nice. >> Yes. >> I'm not going do that. >> Powerful and nice,
but I understand. I'm a fan of the
Classic Editor as well. >> Classic Editor has called me, but you can also export that to YAML. >> Absolutely you can. >> Okay. So we're going to start with Classic Editor and here's
why I like Classic Editor, because it helps me and walks
me through what am I doing? So here, I got lots of options. We know that my code lives in GitHub. >> Cool. >> Now, we're going to do, I
like this because you have Bitbucket and other Azure Repos,
needs to authenticate. So here, I'm logged in with GitHub. >> Nice. So you get it. >> Done. >> I'm going to search
for repo, right? >> Yes. >> Say HelloDevOps, select. >> Perfect. >> Then I guess I have
all my branches right, it's smart enough to know that
there's branches in here, master is good for me. >> Cool. >> So this is what I really like, I could start with YAML, but I love that the team
has a bunch of predefined- >> Templates. >> Templates. Yeah, I'm
a big templates person. A lot of people command like people. I'm a visual person,
not going to lie, and I like that there's
a Xamarin one in here. >> Nice. >> Because this is our app
right here, it's a Hello, GettingStarted, iOS, and
Android Xamarin application. But notice though
that inside of here, there is all sorts of
things for Azure Functions, ASP.Net Core, Xcode
builds, Android builds. >> Literally, you can build anything you wanted and
do whatever you want. It fully customized build system. >> Yes. So inside here I might
get started with Android per se, but then we can add more. >> Sure. >> So I created this work, I don't know what's happening. >> All right. So
the build system inside of Azure Pipelines is basically
a task-based engine, right? >> Okay. >> It does one task after another. >> So what I'm seeing here is
like this agent and then tasks. >> Yes. So an agent
that's going to be the machine that's going
to build your application, that's going to do all
of this group of tasks. So literally, if you look
through this list it saying, first, let's restore
our packages from NuGet, then let's go ahead and build
the Xamarin project and then, let's go ahead and use
some signing that happens, and they have some tasks
that are disabled as well. I'm guessing those are like to test and also distribute things like that. >> Yes. So what's
cool is that we have those App Center project set up and here what
we're actually seeing is, you're right, these
are optional things. Because, hey, you may not be using App Center to test and distribute, but they give you the option
here which is nice. So we want to set up something
super simple testing for this and I'm noticing here
we have these agent pools. >>Yes. >> That's a lot of agent pools. >> Yeah. So it's really nice too because you don't even need
to have build machines, if you use Azure
Pipelines, Microsoft, we supply you with agents
on all three platforms. >> Cool. >> All right. So Windows of course, Linux and also Mac. >> Very cool. >> Which becomes super
important for you, for the mobile world if
you're building an iOS app. >> It's got to be on a Mac. >> Yes. >> An Android can be built on a Mac, so we're going to say here, lets set up everything on a Mac, and we'll say HelloDevOps-CI. So we're going to build
not just on Android, I'm also going to
build an iOS app too. >> Nice. All-in-one built? >> All-in-one built. In fact, I'm going to do it in multiple. What would you call this chunk here? >> It is like an agent phase. >> Agent phase. >> Yes. >> So here, I actually can tap on
that agent phase and we'll say, Agent Android for instance, right? >> Yes. >> So now, this is my Android phase. >> Yes. >> What's cool about, like here
is that they're different, I can say do parallel, do multiple agents, do time-outs, like for the Android
part to do this stuff. >> Yes. >> Inside of here, what I like, I did practice this earlier. Now, I know an Android on Mac, I'm going to have to do something
a little bit different. So what I'm going to do
here is I'm going to say I really want to enable NuGet. >> Okay. >> I'm going to restore my NuGet, but I'm going to restore
my NuGet on my Android project, and I love this. >> Yeah. >> I pointed to GitHub, it's like this code is
not in Azure DevOps, it's over on GitHub, but
it shows me everything. >> Yes, seamless integration
is what we're going for. >> I love it. So we're going
to say, restore NuGet, and instead of using
the NuGet command, which tries to select
at the solution level, what we're going to actually
do is just do that. >> Project level. >> On my project level. It'll be faster in general. >> Yes. >> Then here, I don't
like magical reg access. I know that I have one Android
project that I want to build. >> Yes. >> So I'm just going
to pointed at it. >> Draw right to it and select it. >> Done, and that's it. For this instance, we don't
even need to sign anything, we'll leave this enabled. >> Okay. >> For Android, there's this
cool thing which has to be done, which you have to zip align
and sign your package. >> Yeah. >> You have to do it if you
want to install it on a device. But we're just going
to do is smoke test, we're going to leave it at that. >> Okay. >> The other thing that I want
to do here is, I love variables. There's private variables,
public variables, groups, there's all these things. >> Yes. >> I'm going to set
the default release here to debug just for fun, is okay? >> Cool. >> We're going to change that
in the future but for now, just to get started we're good. So I also want to add
another agent phase. Okay. So we're going to add that
there and we're going to call this agent iOS phase, okay? >> Yes. >> So we're going to
do a few things here. So what I love is, even
though I added a new phase, I have all these things, look at all these things. >> Yeah. Out of the box, there's like hundreds of tasks
that do all crazy stuff. >> Yeah. I even have
my own Azure DevOps extension in the marketplace that does
version bumping for mobile apps. >> Perfect. Nice. >> We'll do a whole episode on that, I'll walk through why
that's so important. >> Yeah. >> So lets do NuGet again, and we're going to copy and paste almost what we
have up here on Android. So on this use NuGet, we're just going to tell it, "Hey, we want 4.4.1,"
just so it matches. Here, I'm going to do NuGet again, and here I'm going to go ahead
and say "NuGet restore". I'm going to do it on the solution. >> iOS is on this solution
level. That's right. >> Different, it's weird. >> Yes. >> Then here, I'm going
to type in "iOS". We're going to put in Xamarin iOS. >> Yes. >> You're actually
seeing all of my special James Montemagno extensions in here. >> Very cool. I may have
to check him out later. >> So here, this is going
to do configuration, but they has a card coded in
there, I don't like that. >> Okay. >> If I look at the Android builds, I'm going to use that variable. >> Okay. >> Okay. >> Just so if we
change in the future, we're going to build it for both. >> Nice. >> Now, we have the option here of generating an app package
or building for simulator. We're smoke testing buildup
for simulator. >> Perfect. >> We're good to go. But
these are both going to be built on the marks because we're going to inherit from this pipeline. >> Okay. >> That's it. I literally
just setup a whole pipeline. >> So it's a pipeline that builds your Android and also
your iOS in one build. >> Exactly, but in multiple phases. So they're going to
happen at the same time. >> Yeah. >> So let's just see if this works. >> Okay. >> Crossing fingers, I'm saying schedule something
and I have it built. >> What could go wrong? >> What could go wrong? Now, this is cool because, remember, we set up two phases. So there literally is two things
that are going to happen, and you mentioned
that there's agents. So there's just like
all these agents, just floating around in
the Cloud somewhere? >> They are. Whenever
somebody needs it, we spin one up for you and
bam, it's just for you. Code gets downloaded on it and you'd actually see exactly
what's happening here. It does all the tasks that you just said and when it's
done, we blow it away. >> Beautiful, I love that. I love that it's just like
so simple, streamline. I love that I can see the steps
of what's happening here. >> Each individual step, you can scroll in there to see. >> I love that, like here
it's resorting NuGets, and this is happening like a
different machine. I'm thinking that- >> It's in the Cloud. >> It blows my mind. If I'm a developer today, I have to build my iOS
app, let it compile, do the thing, package it, go to my other project, the iOS or the Android one. Do it again, package it, I have to sign, to do other things. Am just sitting and I'm waiting, and that's based on
the power of my machine? >> Yeah. Now, you can just
use the power of the Cloud. >> I understand. >> Let Microsoft worry about that. >> Yeah, I think that there's an infrastructure
there that's doing it. I want to see how fast it does. What I love is that I don't
have to wait around for- >> Yeah. Well, it's building
both in parallel, right? >> Yeah. >> That's freaking
awesome. I love that. >> That's so cool, and I like it that there's a summary of what's going on, so I can see any
associated commits to. I get actually a lot
of information here. >> Oh, yeah yeah. >> If I had test, they would
actually give me test output, but no tests yet, but coming soon. >> Yet. >> All right. So far it looks
like we have one green. I'm very excited. >> All right. Wow, a lot of them green. Like I
said, what could go wrong? >> What could go wrong? So
from here, what do I have? What's this Release and
Artifacts, I guess? >> So that let's you see exactly
what your release pipeline is, and if you don't have
a release pipeline, it'll take you and you can start
creating a release pipeline. >> That's cool. So if I wanted to
from here, I could create one. >> You just click it and then
immediately you start building up your release pipeline
for that specific build. >> How cool. >> So it makes things easy for you. >> I'm not ready yet. >> Yeah, I'm not either. >> That's a whole another video. >> I'm still kind of at awe that you just created
a build that quickly. >> Now, I do want to
point out one thing here, if I go back to the pipeline. Is if I wanted to, I can say build this on Visual
Studio 2019, on a Windows machine. >> Yep, you can. >> If I had an ASP.NET website, I could set up another phase to build my mobile apps and
our website at the same time? >> Yeah. So lot of times when
I create my mobile builds, they're usually for
some pretty big projects, right? >> Yeah. >> So then I have a phase
that builds my Android, phase that builds my iOS, then I have a phase that builds my front-end web server or web app, and then I have another phase that builds a lot of
my back-end code, because a lot of times
I have like rusty API's or functions or whatever, in back-end talking to SQL Server
or Cosmos or whatever. >> You want to deploy them all. >> I want to build it all. >> You want to build it all. So
the last thing I want do here is, I want to set up a trigger here, because I want to set up
continuous integration. Because actually, we haven't really
done anything continuous yet. >> So when you talk about
continuous integration, basically you're saying
if I check in code, kickoff the build, right? >> Yes. >> And you gave me some options.
Can you walk through what these options
are inside of here? >> Sure. So when you
first turn it on, you have a trigger to say turn it on or off if somebody checks in code. Next, there's basically some filters
that you can work through. One of the filter is
based on the branches. So if somebody checks in code to a specific branch, then
kickoff the build. >> Got it. >> Or you can easily filter
on not only just the branch, but also which directory structure
within your branch. So if somebody checks in code
within this specific directory, then kickoff this build. >> So I could have
multiple branches inside of it then include or exclude. So do everything Botmaster. >> Yes. >> Which would be
kind of interesting thing to do if you want to
do something special. Now, I love this feature which
is Pool Requests validation, because I have a build from master but I want to make sure if someone is now committing code to this Repo, they send me the PR, right? >> Yes. >> It might be a fork. I want to make sure that they
know that it built, like they didn't break the build. >> Correct. >> And I love this. >> Yeah, it's just a checkbox
and, bam, you're done. So anytime somebody does a PR, the first thing it does is it kicks off the build mixture it compiles, if it doesn't even compile, why do I need, you to
review your code,right? >> Yeah, totally. And
I like that here, you can control the security of it, whether there are secrets
available, no secrets available. Do you even allow forks or do you only want to
work from your team? >> So that's the nice thing
about Azure DevOps, is that you really get super fine-grained control
over pretty much everything, which makes it a little bit more
complex to setup and use as well, but I like having that power
of really tightening it down as much as I need to or opening
it up as much as I need to. >> Totally. So I'm going to come
back over to my GitHub Repo, and let's go into the branches here. Because what I want to do
is, I want to add a rule that require pull requests, maybe not reviews but status checks. >> Got it. Okay. >> Now, of course I remember
we selected the GitHub Repo. I can't make sure
that is actually run. It knows, it already
communicated that, Hey, you have some continuous
integration set up here, and why don't you just make
sure that that thing passes, and we'll call this Master PR. Others should be for Master,. So we're going to set up four master, and then make sure that
I set this up again. Check here, required,
then we'll create it. >> So now basically you're saying, don't accept the poll request unless it's built and
it was successful. >> Exactly. So let's
do a poll request. >> I love that integration. >> It's so good. So I have
this hello DevOps here, and why don't we just add a
"Readme" because why not? >> Okay. Sure. >> So this needs a "Readme". Maybe we'll put that,
we'll add the "Readme", and then we'll say
this needs a "Readme". >> Okay. >> There. So this is
committing it into here, we're going to commit that file and then we're going
to do a poll request. This is how I work. I never commit to master. I always do it as a branches, and then this was mind-blowing
about this entire process. As I did a poll requests, it already knows over here that is expecting a status,
and now it's queued. >> It queues it and
it starts running it, and will even give you a little flag that tells you if it passes or fails. >> Its so cool and
effective. So if we go back over and we go to our builds- >> There it is. >> There it is. >> Nice. >> It has the branch on it too. It get to knows that there's
a branch associated with it. If we tap into it even further- >> You can see everything
that's happening. >> Yeah. It's really cool because I sit here and I
was like, "Wait a minute. What's happening? What's going on?" Then you'll get a green checkbox
and everything's good to go. >> Yeah. >> So now, I know if
I break the build, it's no going to pass. >> Yeah, and you that as
soon as the build's done. >> Exactly. And that's
like the start, right? >> Yes. You have to
have this to start. >> Right. >> We need to be able to
go through check in code, needs to kick up a build. Let me know if it passes or fails. That's the beginning. >> Literally in 20 minutes, we set up not only our code
which is in GitHub, a full CI pipeline with continue integration and
checks inside of GitHub, inside of Azure DevOps,
and get out together. >> Within 20 minutes. >> That's amazing. >> I love that using
this build pipeline, you really can customize it and make it do exactly what you want it to do. >> Yeah. >> You're not constrained in any way. >> You're not, and you even saw
inside of the pipeline today. If I go into that build pipeline
and I go into "Edit", I can come back in and I can
add any of these tasks, right? >> Yeah. >> I can put in
utilities, I can deploy, I can do bash commands,
I can do scripts, I can do anything inside of it, which is super powerful. And you can see already, there's a lot of things that I'm going to be doing in the future here. Which is, yeah, I"m
going to be publishing tests and stuff in the future. >> Yeah. Oh, I can't
wait to see that. I'm really excited to see
the distribution part because that's the part that's
tweaking me out right now. >> It does. It's funky and I
can't wait to talk about it. >> Nice. >> Abel, thank you so much
for joining me and really describing the tools that I use every day in more
details than I knew, because I was like, "What
does that do?" Very cool. Well, I hope that you
enjoyed this episode of DevOps for Mobile Developers. We've a lot more in store. But if you didn't watch
the previous episodes, go to that playlist. Go watch all that other stuff where Abel and I talked about what is DevOps and how to even publish a code into GitHub
with just a few clicks. Hope you enjoyed this video. Check out the comments below. Please give us your feedback,
we would love it. That's going to do it. Abel,
thank you for joining me. >> Thank you for having me, again. >> Yes, and thanks
everyone for joining us. [MUSIC]
