Learn about Mobile DevOps with Xamarin, HockeyApp and Visual Studio Team Services
Articles Blog

Learn about Mobile DevOps with Xamarin, HockeyApp and Visual Studio Team Services

August 10, 2019


Good morning everyone. Let’s try that again. Good morning everyone!>>Good morning!>>Perfect, you gotta give it to me,
I just flew from Houston, Texas, where it’s warm right? Who does Chicago in January? When I asked Siri what
the temperature was and she said 32 I went and
asked Cortana too. They both said the same thing. I was very upset. No, this is not warm, man. I live in Houston, Texas,
where it is perpetually hot. And it has 1000% humidity. It’s awesome. It’s good for your skin. I might not look it,
but I’m 80 years old.>>[LAUGH]
>>So humidity’s good for you. My name is Donovan Brown, I’m a principal program
manager at Microsoft. I’m responsible for the DevOps
division on top of Team Foundation server and on top of
Visual Studio Team Services. So, I work with people like James,
who does mobile and I figure out how am I gonna
rub DevOps on mobile? How am I gonna rub DevOps
on Docker and SharePoint? And all the other things that
exist in the technologies. And I figure out how Team Services
and Team Foundation server are going to ease the pains of doing that
development on the daily basis. That is my job. The best way to get
a hold of me as Twitter. It is the number one way to get
a hold of me and to follow me. If you have any questions
about what we do, James and I are very active on Twitter and
we will answer your questions. If I don’t know the answer,
I just did it yesterday, I will add a guy to the conversation
that knows the answer. You’re talking directly
to the product groups. The people who actually make
the products at Microsoft. If you feel some of our competitors
do something better than me it’s @DonovanBrown. I take challenges very,
very seriously. The reason that I put the little
competitive things at the bottom, the air hockey and
the car racing is just so that you know how competitive I am. If you honestly believe that Jenkins
is doing something better than our build system, I need to know. Cuz I will go make our
build system better. I install Jenkins and Bamboo and
Bitbucket and all the other type of products because I need to know
what they do that makes them good so that I can make our products great. I take it very, very seriously. If you need help definitely
follow me on Twitter. I also blog quite a bit
at donovanbrown.com. So you can follow me there as well. All right, so what are we
going to talk about today? We’re going to be talking
about DevOps today. And I’m pretty proud of this
sentence cuz I actually wrote it and it is the definition
that Microsoft uses. So if you go to
visualstudio.com/DevOps, that’s the definition
of DevOps that you see. 30 days it took me to
write that sentence. 30 days of soul searching. I’ve been writing software for
20 years. And when a company that has 200,000
employees selects you to define DevOps for them,
it’s a lot of pressure. So what I did first is I reflected
over my own career as a developer and said, why is DevOps the hottest
topic on the planet right now? We have conferences over it,
books over it, products that are trying
claiming that they enable it. But why now and not ten years ago? And that’s what I wanted to
answer first before I ran off and tried to come up with yet
another definition of DevOps. Cuz trust me there’s
dozens of them out there. Everyone claims to be
the person who defines it. But I needed to define it for
Microsoft, so that I knew what our north star was. What it is that we’re trying to do,
every single day we come to work, to enable DevOps for any language,
targeting any platform. So why is it hot now? I’ve been developing,
like I said, for 20 years. I started off at a little company
called Compact Computers. Anyone old enough to remember that? I told you I was 80, right? I loved Compact Computers. And we were back in
the old Waterfall days. Remember that, where you’d do all
the requirements gathering up front? You go and you code for six months. You throw six months worth of bugs
over the fence to the QA team. And they have three weeks to get
it ready for production, right? And it’s never what it
was supposed to be. And I remember that world. And I also remember the world where,
when I was done with the software, I could go onto the production server
and login with my credentials. You guys remember those days? And then copy files around,
change registry settings, do whatever you wanted to,
cuz you owned that machine? And then the lights would go out. And the Ops guy would
get pissed off. Why is he upset? Because not only did you
take down your application, you took down every other
application on that server. And now he’s getting emails and phone calls from the people whose
other apps are now affected, of the fact that you were
on that particular machine. So what did you have to do? You had to stop touching
the machine and start writing documents on
how to install my software. And then give the poor
Ops guy a binary file and say you now go install it since
you don’t trust me on the machine. My document was much
worse than my software. It had gaps in it. It was very optimistic. I assumed everything went perfectly. And the poor guy starts, you’re laughing [LAUGH] because you
wrote that same document right? It’s horrible. If you’re a developer you
hate writing documentation. That’s the definition of developer,
right? Hates to write documentation. If you wanna know how the software
works go read the software. That’s how the software works. Why do I have to document it again,
right? So, we hate writing documents. So, they’re horribly bad. And the poor guy would go and
try to install it. All the lights would go out. And everyone’s still mad. So ten years ago what we had to fix
was our ability to write software well, right? To deliver on time,
deliver under budget. And how we fixed that is
that we came up with Kanban, and Agile and
test-driven development and the string programming and
paired programming. And what this allowed our companies
to do now was to produce value very, very quickly. Producing value and delivering
value are not the same thing. Teams are now able to produce it,
but they’re still weeks or months from the time that the
software is done to the time it’s actually in the hands of our
developers or, I’m sorry, our users. And that’s what DevOps
is here to fix. I always joke that what we’re gonna
do is we’re just gonna rub a little DevOps on it and we’re gonna fix
this distrust that has been built over decades of developers and
Ops people hitting head to head. So what is it? It’s the union of people,
process, and products to enable the continuous
delivery of value to our end users. I can defend every
single word of that. Why did I say value and
not software? Cuz it’s not just about
copying bits to a server. It’s about delivering
value to your customers. And guess what? It’s called DevOps. Ops people can actually deliver
value without changing a single line of the application. It’s about value. So let’s say for example,
I have an e-commerce site who can only sustain 1,000
simultaneous users. And Christmas is coming. That’s gonna be a problem. But an Ops person can go in and fix
our infrastructures, scale it out, scale it up. And next thing you know, we can now do 10,000,
20,000 simultaneous users. That’s value that was just added, without a single line of your
application being changed. It’s how Dev and Ops come
together to deliver a value. There’s nothing I’m going
to say to you today that you don’t already know. I’m gonna talk about
continuous delivery. I’m gonna talk about
continuous integration. I’m gonna talk about testing, and
you’re going to all be nodding like, yep, we all get that. Then I’m going to say, are you
doing it in your organization? You’re going to go, nope. We know it’s the right thing to do,
but we’re not doing it. Why? Because of the people. There’s someone in your organization
that just does not believe. There’s someone in your organization
that’s been doing it the same way for 30 years. And they’ve gotten successful in
where they are in their career doing it the exact same way for 30 years. And now here we are telling
them that they need to change. And it’s hard when
you’re successful. When you’re number
one in your industry, doing it the way that
you’ve been doing it, why on Earth would you break
something that’s not broken, I mean fix something
that’s not broken. The people have to change. The reason you have to change is cuz
your competition is already doing this, right? Uber just completely
wrecked shop over taxis. Amazon did the same thing in retail. They were thinking differently,
the other people were too arrogant, ignorant or stubborn to realize
that they needed to change and now, they’re the ones playing catch up. That we’re at one point number one. You gotta get your
people to understand. The process, guys,
that’s the easy part. We already know how to do this. And what I do as a product manager
at Microsoft is I try to produce the best products on the planet. And if I can do that, I believe I’m
gonna help you convince the people. So they just see a really
slick piece of technology. That it’s just obvious that’s
gonna make my life easier, then maybe it’s gonna be easier to
convince them that they need to start changing the way that
they’re doing their job, right? So to me, every time I say DevOps today,
that’s what I’m talking about. All right, so
we’re gonna talk about a very special type of DevOps today,
though. We’re gonna be talking about
mobile DevOps, which I personally believe is the most difficult DevOps
pipeline you’re gonna build, period. What I’m here to say, and
I’m really happy to say, is that Microsoft’s gonna
help you along the way. Why is it so difficult? Because mobile has so
many unique challenges. Just the development of
a mobile app is a challenge. Do I use Cordova? Do I use Xamarin? Do I do Native? Do I go to Xcode, or
do I go to Android Studio? Do I do it on a Mac, or do I do it
on a Linux, or a Windows machine? Just getting started with
mobile scares you to death. And after you have your
first line of code written, guess what,
you gotta go test it, right? Cuz it all starts with the developer
checking in code, hopefully, right? He commits code to a repository. And what’s really cool about
Visual Studio Team Services and TSF is we offer you
two different types. If you want distributed,
which I hate by the way, I think it is the worst thing ever. If you like it, we got it, so
don’t worry about how I feel it, as long as you love it,
we have GET for you. Unlimited private repose, as much as you want,
we don’t charge you a dime for it. If you still like centralized,
check in, check out, we got that for you too. But what’s going to
happen is that developers are going to check and code. And it’s going to go
to our repository. That repository should then
kick off what we call a CI or Continuous Integration build. We’ll talk more about
every one of these things. CI basically means that I’m
gonna download the code, I’m gonna compile it, and then I’m gonna run some
unit tests for you as well. To make sure that
it’s good instantly. No longer waiting. I remember when I was at Compact,
we used to do a build every Friday. Which means I wrote bugs on Monday, I wrote bugs on Tuesday,
I wrote bugs on Wednesday, I wrote bugs on Thursday,
and I wrote bugs on Friday. And then they would build it. And they’re like, Donovan,
you broke the build. When? Well we brand a build on Friday. Yeah, now it’s gonna take me two
days to figure out which week’s worth of bugs I wrote
actually broke the build. Had you told me sooner,
I could fix it easier. That’s what CI does. You’re checking code at 9 o’clock,
9:03 the build broke. Guess what?
I know exactly what I was working on. It’s really easy for
me to go back in and fix that. That’s what
Continuous Integration gets you. Okay? Then we wanna run automated tests. And this is one of the scariest
parts of mobile, cuz there’s so many freaking devices, right? So many shapes, sizes, operating
systems, vendors, it’s just nuts. And to be able to try to do this
with what you have on your desk is impossible. And we’re gonna talk about really
cool features that we have that make that really easy for you to do. And then you have to distribute it. Which again, is very painful
when it comes to mobile. It isn’t just putting
the files on a server and now everyone has access to it or
they can go download it. It has to go through a store and get
validated and it’s just a nightmare. But we have a cool piece of
technology that fixes this for you too. So luckily for you,
you’re coming into mobile for those who haven’t started. At a time where we figured out
the majority of this stuff for you. To deliver a value, you have to monitor the application
as it’s running in production. You can’t just copy
files to a server and pat yourself on the back
like you delivered value. If I just added a new feature, but no one is using that feature,
you did not deliver value. You just copied files to a server or downloaded them to
your mobile device. But if no one is using that new
feature that wasn’t value right? That was just an exercise to
see if we could deploy these new files to a server. But to monitor the application
to see that people are actually using it. That’s how I valued that I
actually delivered value. And that’s important information
that I can then use in my product back log. To make sure that we continue to do
things that are actually delivering value to our end users. Not only can we capture things
like crashes and statistics. We can also get feedback
from our end users. So they can pat us on the back and tell us about things that
they like that we’re doing. So that we continue to
do more of that as well. We at Microsoft enable every bit
of this for you automatically, and that’s what I’m going
to show you today. All right, I work on this team. We build two products,
called Team Foundation Server and Visual Studio Team Services. They are essentially two
sides to the same coin. One of them,
you install yourself on-prem. The other one, you host, or we host
for you in the cloud automatically. They offer you everything
that you need to turn an idea into a working piece of software,
everything. Work item tracking, bug tracking,
test case management, source control,
continuous integration. Continuous deployment,
package management, everything from one vendor, right? It’s unprecedented. No other vendor on the planet
gives you all of this. Many of them are trying to acquire
and gather this stuff now. But if you’re building
a DevOps pipeline today, and you’re not using Microsoft,
you have more than one vendor. I don’t have to ask
you any questions. I know that for a fact. Because we are the only ones
who have everything, okay. Quickly others are trying to gather
it, but we’re the only ones. Reducing the number of vendors in
your DevOps pipeline makes your life easier. Because every time you add a new
vendor, you add a new tax. The tax is keeping that tool to
talk to the rest of the tools that are already existing
in your pipeline. And if you don’t have us do it for
you, then you or someone at your organization
is doing that today. Right, so when you take
build from this company, and release from that company, and
something else from that company. And you try to stitch it together, it now became someone’s
job at your organization. To make sure that that pipeline
stays the way that it’s supposed to stay. That’s time that they’re not
innovating on what makes you money. They’re now innovating on tools that
are supposed to be supporting you, and now they’re
actually a deterrent. So you want to reduce
your vendors count, and we’re one of the vendors
that allow you to do that. Continuous integration, as I just described, is it gives
you the ability to quickly find out if you guys are still
on the right track or not. When people say, Donovan, we are so
in the weeds on this DevOps thing, where should we start? This is generally where I say, because I assume you already
have version control. [LAUGH] If you don’t
have version control yet, you’re in a world of hurt, right? So my assumption is,
you already have version control. Otherwise that’s where I
would tell you to start. Assuming that you
have version control, you should have
Continuous Integration. Every single time
a developer checks in code, that code should be downloaded,
and built on a separate machine. Why a separate machine? Because if I have just added
a third-party reference, that I’ve downloaded
onto my machine. And the code works great, but
I forget to commit that third party reference or
I forget to update my package files. Then what happens when
the other guy downloads it? It doesn’t work anymore, right? It worked great on my machine, so
building it locally on my machine does not verified
that it isn’t broken. It just means it’s not
broken on my machine. And we’ve all been there.
It works perfectly on my machine, right? My boss used to threaten
to shoot my machines. Cuz that’s the only place
where it worked, right? But if you have a check and
go back and say, hey I can’t build this either. I’m on a clean, virgin machine. I downloaded the latest
version of your software. It doesn’t build anymore. And I can tell you this
within a couple of minutes. So that I can go back and go, my god, I forgot to update
the package of that JSON. Or, my god,
I forgot to update so and so. Let me update that real quick. The build is now green, and everyone
on your team can safely do a get latest and
continue to work effectively. That’s continuous integration. Now, not only do we offer
continuous integration. Tied tightly into continuous
integration are things like version control, which is where
all the code comes from. So you commit to version control. And then we download it and
we build it. We also do Agile planning for you,
so your bugs, your test cases, your tasks, your requirements. We can actually take
that information and associate it to the code
that you just changed. So that when a QA person comes and
says, hey, what files did you
change to fix that bug? You can simply say,
go look at the bug. Because it’s actually attached
to the files that I changed. So they can go back in and
do impact analysis and all kinds of cool
statistics on that as well. And then that obviously ties
into our continuous integration. So what I’m gonna do
now is I’m actually gonna show you our
continuous integration. Let me go over to web browser here. So this is
Visual Studio Team Services. This is just a dashboard
that it will generate and I can actually create it for me. And this is a very mobile
specific dashboard. You can see I have
a mobile CI running. I have HockeyApp down here in
the corner which allows me to go to the distribution, which we’ll
talk about later and release. So we’re gonna talk about all these
different portions of it, but today right now we’re gonna
go focus on our CI build. So this is just basically giving me
a chart of how my build’s been going over time. As you can see, I’ve had some fail. I’ve had some of them succeed. And if I want to, I can just basically drill down into
one of these build definitions. Now this is a build
that actually executed. And I love how we have this nice
surface area here that gives you everything that you need to know
about that particular build. All the different tasks
that we performed for you. And this really nice
thing that says, hey, these are all the tests
that we ran for you. Which we’ll talk about
more in a little bit. What the results of
those tests were. What work items, if you had
associated any work items to this check in, that were associated here. How we distribute this over
to HockeyApp for you as well. And even take you to
those test results so that you can see
a really cool display. But I don’t want to
spoil the surprise. That’s one of the cooler parts,
is our Xamarin test cloud and I’ll show you that
here in just a second. And then even release management. But how did I get here? The way that I got here is I created
something called a build definition. If the last time you looked at
our build system was 2013 or earlier than that,
please look at it again. All right, we understand our
build system was tough to use, it is not tough to use anymore. I promise, right. We learned from all of our mistakes. Like I said before, we installed
our competitors’ products. We saw what our customers and our competitors liked
about those products. And we came in and we incorporated a
lot of that into what we do as well. No longer are you hidden
away inside of XAML. What we give you now
is a little task list. As you can see here, I’m replacing some tokens in my
iOS and my Android applications. I’m able to build them. I’m using Xamarin, which you’ll learn more about
in James’s talk later today. That allows me to write code once,
yet target all the different platforms. So I don’t have to write it in
Xcode and then go ahead and write it inside of some
other language for Android. And then yet
another language for Windows. I write it once, and
I’m able to build it and deploy it to all of
the different platforms. I’m also able to use the Xamarin
test cloud which we’ll talk about in a moment. To actually run tests
during my build. So I’m not only verifying
that I can compile the code. I’m verifying that the code
actually works as expected, before we leave
the build altogether. And then I’m gonna be using a piece
of technology called HockeyApp. Which allows me to
get early testers and individuals involved in
getting me feedback. And tracking their statistics
before we actually push it out into the store. We can add as many
tasks as you want. And we are basically ready
to help you build anything. So if you want to do Docker,
we’re ready for you. If you want to do Android. There are a lot of you
who are doing mobile. If you started before Cordova and
started before Xamarin, you are doing X coding,
you are doing Android Studio. That’s fine for us. This is a new age for Microsoft. This isn’t the Microsoft that says,
if you want to play with us you have to be .NET and
you have to be on Windows. Right? I have a Mac at home,
actually I have two Macs at home. I have a Linux machine at home and
I have a Windows machine at home, because I work at Microsoft. I actually installed Linux for the
first time after I joined Microsoft. All right, did you hear what I said? After I joined Microsoft, I
installed Linux for the first time. All right, it’s a really weird
time for us at Microsoft. But I love it because it’s
no longer just Windows. We all carry multiple devices. We all have to know multiple
operating systems, and even multiple programming languages. Cuz it’s not just .NET anymore,
okay? So if you wanna do Android, great. If you wanna do Java,
that’s fine with us as well. Well obviously we’re prepared to
have you deploy all the way into Azure, whatever it is that
you’re wanting to deploy to. And these are just tasks. And these tasks,
you just add them to your build. You configure a few items on it and
then they’re ready to rock and roll. You can do anything that you want
from any command line on Mac or Windows or Linux. When you’re doing a continuous
integration build, the heavy lifting is done by
something called an agent. The agent is the piece of code
that gives the requirements, and then goes off and
builds your code for you. Our agent installs on iOS. Not on iOS, I’m sorry. On Mac, and it installs on Linux,
and it installs on Windows. So whatever platform you actually
want to build your application on, we’re there waiting to
do the build for you. And we had to do that because to
build iOS, you have to be on a Mac. There are no exceptions
to that whatsoever. So our agent installs
perfectly there and it runs there and
it’s waiting for us. So I have a Mac Mini on my desk
in Houston, Texas right now. If I issue a build, that guy wakes
up and goes and builds my code for me for my iOS, stuff like that. So it’s really cool. And if you don’t see a task in here
that you want, you have two options. One you write it yourself. They’re really,
really easy to write. You can write them in PowerShell or
you can write them in Node.js. Or you can simply go
to our marketplace. And our marketplace is where vendors
and companies and partners and even some of our competition. Have basically gone in and
started writing extensions for team services. These extensions have
build task in them. Remember that dashboard I showed
you that had the HockeyApp widget? That is a widget that
comes from an extension. So you install the extension and all of a sudden you can
build better dashboards. You can run cooler builds, you can do all kinds of cool stuff
inside of Team Services and TFS. Because of these extensions
that get written. Guys like myself actually
[INAUDIBLE] one of mine. And there are a lot of us who go and
write these things to make everyone’s life easier
using Team Services, okay? So don’t think that you’re stuck
with what comes out of the box, even though what’s
in the box is great. You can obviously extend it to
fit your needs as well, okay? I guess that it runs natively
on Windows, Ma,c or PC and getting started with the build
definition is really easy as well. So if I wanna recreate a new build
definition, that’s a release sorry. Back where we can do build. I’m gonna show you just how
easy it is to get started. For any language
targeting any platform. So if I wanna create a new build,
you can see that we have templates. So we actually know
how to build Xcode. We already know how to
build Java applications. So if you guys are using Maven,
or you’re using Gradle, or you’re using Ant to do your
Java builds, that’s fine. Don’t think that this is just for
Microsoft stuff. That’s really important to me that
you understand that Microsoft is now helping you do language
on any platform. So our CR system, I’m a big fan
of it, I think it’s fantastic. And that dovetails, that’s kinda
like the first domino that falls in the DevOps pipeline is that
code getting checked in and that build kicking off and then all
this other cool stuff happens after. So, let’s go take a look at some
of the other cool stuff is. All right, this is the scariest
thing in the world. This is just a representation of
what it would be if you wanted to try to test on the landscape
of devices that exist today, all mobile devices. The screen resolutions,
the sizes, the shapes, the OS, the manufacturers. No one in their right mind would
try to collect all these devices to be able to say we are not
going to be able to safely run on what our customers
are going to run against. And we need a way to be
able to do this, but no one in their right mind will
try to collect all these stuff. What we have is Xamarin test cloud. Xamarin test cloud allows
you to white test, and I’ll show you what one of
those tests looks like. And then when you
check in your code, you’re also checking in
the test that tests that code. We will upload those tests
to this environment. These are physical devices. These are not virtual machines,
these are not emulators. These are physical devices
sitting in a data center. We have a partner that also has, we have a partner
called Perfecto Mobile. And before we acquired Xamarin,
they flew me up to Boston so I could go see one
of the data centers. It’s the freakiest thing you’ve
ever seen because you walk in, it looks just like a data center,
just rack and rack and rack. But as you get closer there’s
no computers in there. There are just phones
just laying everywhere. With all the little
USB cables on it. And I was just lucky enough to look
down at one as a test kicked off. You literally see the software
install itself on there. It fires up and you just see the
application being exercised and then all of a sudden they uninstall it
and they give the test results back. It’s amazing. And we have thousands of devices
sitting in data centers, waiting to basically do
your builds for you. And when I did my CI build, when you saw those test results,
they were run in this test cloud. I said these are the devices
I want you to go find. Here’s my code, here are my tests. During my build it went and
provisioned those machines, like basically reserved them for me. Installed my software on there,
ran my automated tests, and then reported back what
the results were, right? So this is amazing technology
that allows us to run these tests automatically. Manual testing and exploratory
testing, you still need to do that. But you need to automate as
much as you possibly can. And this is a great way to be able
to automate your testing as well. So let me go take you
into Xamarin Test Cloud. So if I take you back over here, and
I can get there from my build again, which I really like as well, is if I wanna come through,
let’s look at our build. And from that build output I had, I don’t have to go to Xamarin
test cloud explicitly. I can actually just
come down here and click on a link that basically takes
me right to the place I need to go to be able to see the results
of my particular test. My mouse is green up here. So this is gonna basically
take me to Xamarin test cloud, where I can go back in and see the results of the tests that
were run as part of my build. Now, I can run these
as part of my build, I can run it as part of my release. It’s completely up to you. What I really like about this is,
it tells me how many tests I ran, if they passed or failed, how many devices I
used on them, the run time. What the actual OS’s were
on the devices that I used. If I was using tablet versus phones. And I can even see if I’m peaking
out people’s memory on their devices or we are gonna have trouble
running on a small device that doesn’t have a lot of memory
right here from heads up display. I can then drill into a particular
task that I executed and you actually get to see
the phones as they were actually executing your test. If I were to go through and
I had an arrow in a particular step, I could actually click on that step,
click on the phone, and see exactly what was
happening on the phone. I didn’t have it configured now,
but you can configure video to be recorded as the test
is being executed. Instead of you having to go back and
manually run it yourself you could simply watch the video of
the test being executed. What I had to do
instead was basically, just take a screenshots at
every single step of my test. In addition to this,
I have more statistics. I can see what the memory usage
was on this particular device, what the CPU usage was on
this particular device. If I wanted you to get more
details on that particular device, to see if I actually have one
of these physically in my personal collection of devices,
I can go and see that, so I can go back in and
try to fix this. And I think my resolutions
gonna kill me here. I don’t know if I can
close that thing now. All right so
we’re gonna go back to this site, cuz I think that opening that up
screwed up my little thing there. I’m also going to show
you how quickly you can queue one of these too. So this is another view of that
same information, run after run, letting me know how I’ve
been doing over time. And let me jump back into this area. So I just wanted to show
you one more thing. I can go through every single step
of it and I not only have device logs, but I also have the test logs,
so I can see every single step of the test that I took to get
me to this particular point. Now you don’t have to run them
as part of your CI build. If you wanted to come up and
test on a specific device or a different collection of devices, you could simply say I’d like
to create a new test run. And then from here we’re going to
walk your through a wizard that says tell me what app you want to test. And then after you go through that
app, my mouse is really messing up. I get to see all
the devices that I have. And it knows that I’m dealing
with an Android device. So what it’s now presenting to me, is everything that I can run
against an Android device. Had I chosen an application that is
iOS, it would be showing me iPhones, iPads, and things like
that here as well, right? So I just wanna give you an idea of
the collection of devices that you can actually go back in,
and go back and look at it. We’re really good at making
sure that we get the devices very quickly. So if you need an iPhone 7,
it’s already in there waiting for you as well. So Xamarin test cloud allows you
to be able to run automated tests against physical hardware and incorporate those results as
part of your CI build, okay? Very cool piece of technology. And then let’s go back over
here to continuous delivery, this is one of the areas of DevOps
that I think I latched onto first. Before I joined Microsoft, I was a
process consultant for seven years. I essentially flew all over
the world installing and implementing Team Foundation Server. And before I joined Microsoft, Team
Foundation Server didn’t do this. Right, all they did was
continuous integration. Which means it would build the code,
it would package it, but then it would just drop it,
like a hot potato. It was like, all right,
this is as far as we go. And our customer was like no,
we need it deployed, we need it on servers. What are you talking about,
this is as far as you go? We need more than this. But Team Foundation Server
simply didn’t have that. And I always felt bad when I left,
because it was like man, I wish I could have done more for
that customer. And sometimes we would,
we would bastardize their build and have it Xcopy files to a server,
but it wouldn’t do approvals, it wouldn’t then go back in and
go from dev to QA and QA to product, it could only ever do one. What we needed was true
continuous delivery. And when I joined Microsoft
is when we acquired a company that actually had
continuous delivery. And it was like, woah. I could see how valuable that was. Because that’s what I had
been missing for seven years, is that this piece of technology. So big,
big fan of continuous delivery. And that’s where you’re able to
take the binary that you produced, and then deploy it from one
environment to the next. And in mobile it’s very unique. Because it could be going
from the Apple store, to the Google Play Store
to the Windows Store. It could be going from your beta
testers and your alpha testers to your stakeholders and
your user acceptance testing. We are able to automate
that entire deployment or delivery of your code using
a product called Release Manager. I’ll show you here in just a second. So another thing thing that’s
really important is being able to distribute the code to
an individual user. I have a sample app
that I’ve written, so you may be able to see
this in real time. But that’s where HockeyApp comes in. And HockeyApp allows us to be able
to take a piece of software and deploy it to a mobile device
without ever having this app show up in the store, which is traditionally how you
get an app to a mobile device. It has to be in a store first. Person goes and finds it,
they download it to their device. If you were going to do this before, you’d have to
jailbreak your phone or put it in some special
developer mode. You’d have to tether
the phone to your PC, and then you would be able
to download bits to it so that you could test it
before it was in the store. But just imagine if you have
testers all over the world. How are those testers supposed
to be able to get the bits? And then it’d be such a pain to
have to tether their machines. So there’s a company out
there called HockeyApp. And HockeyApp had the technology
that allowed us to do this. To be able to take beta bits and alpha bits and distribute them
over the wire, like over the air, to people as if they were in
the stores automatically. And I’m just gonna show
you how that works. Here in just a second as well. I wanna make sure I
didn’t go past it, yeah, I didn’t go past anything here. So let’s go play with our
continuous delivery from distributing beta builds. The application that we use to
do that is called HockeyApp. So HockeyApp allows me to see
all my different devices, sorry, applications. And also, all the different versions
of that application that I currently have in flight. Cuz just because I’m working on
one version doesn’t mean there aren’t other versions
out there still, right? People haven’t
upgraded their phones, they haven’t upgraded their app. This then gives me a heads-up
display of all the different versions and even how many times one
of them have particularly crashed or not, so I can know that this
one version was really buggy. A lot of people were crashing. Luckily, we put out a new version. A lot less people were crashing
that particular version so it gives me a nice heads-up
display of that as well. And it allows me to determine who
gets this particular version of the application. First you wanna go to
your alpha testers. This might be a small
group of individuals. Once they give their thumbs up,
you then wanna go ahead and put that to your beta testers,
which is a bigger group of users, before you then finally bless it and
put it into a store. And we actually
automate that as well. So what ends up happening here is, hopefully this is gonna
work the way I want it to. I have an iPod Touch
here on my screen. Is this sync up correctly? Yeah, perfect. So this is not a simulator,
this is actually a physical device. And People Tracker is a little
application that I wrote years ago for a demo and then I made it
mobile once we acquired Xamarin. Because it allowed me to do that. And all it does is it
allows you to track people. So you put people’s
names in there and it’ll let you check those
individual all over the world. And that is what’s happening now
because I have a new version of that inside of HockeyApp. So all the user has to do is
try to use my application, and they’ll be notified, hey,
there’s a new version of this. Would you like to start testing
that particular version? And what I can do is go ahead and
say, yes, show me the details of this. So the last time I did this, I was in New Zealand, it was warm
there too, by the way, right? So I did this demo there where I
actually was able to add a middle name to an application who
didn’t have it before. It was really cool because not only
did I deploy a mobile application, I had to deploy the backend as well. When people think about
mobile they have to remember, it’s more than just the app
you’re holding in your hand. There’s databases, there’s web
services, web APIs, there’s a lot of stuff behind what you hold in your
hand that also needs to be built, that also needs to be tested, that
also needs to be deployed as a unit. All right, sometimes when I hear
people talk about mobile dev ops, they only focus on the mobile part,
and not realize that there’s an entire back end that supports
that mobile application. What’s really nice about what
I’m showing you here is, it doesn’t care which part it is. It’ll deploy the entire
solution as a unit. So the database goes, the front
end goes, the websites go, and the application on
the mobile app goes as well. Now if I wanted to I
could go back in and I could update this
app if I wanted to. But like I said,
it’s a very simple application. It just allows you to add
people’s names in here. And chrome E User, which is fun, is
actually added by my automated test. Right, so
that’s why the name is weird. It’s because I was using the Chrome
browser of the website that accompanies this mobile application
when I ran automated test not only on the mobile device, but I ran an
automated test against the website that is the sister to
this mobile device. Again, the entire solution has
been able to be deployed and tested as a unit, right, and that’s
where you get the chrome E User. I mean, obviously I had
my name in there cuz I was just screwing around. So what I wanted to show you
there is the ability for HockeyApp not only to monitor and
track all your versions, but to be able to push those versions
down to your testers as well. And we orchestrate that
through our actual builds. So let me show you that
here real quick, too. So if I go back to our build
definition, and I Edit this guy. All that happened thanks to
these last two tasks here. So all that magic of being
able to put out a new version, check out on all of its crashes,
and then push it to a developer, happened because I have those
two tasks at the bottom. Those tasks identify the IPK
that was created and the IPA that was created, or APK,
excuse me, that were created. Pushes them up to HockeyApp and
says, hey, HockeyApp, I need you to distribute these for
me to these select users and then all of a sudden all this
magic happens for you at the end. So it’s part of our build. We can go ahead and do that. We also have releases to where this, these two HockeyApp tasks
might go to the alpha testers. But in the release we have
the same task that says, now I want you to go
to our beta testers. And that only happens after I get an
approval from a user that says, hey, I would like my beta
testers now to see this. I give it a thumbs up. And the systems says, okay, great,
I’m gonna now tell HockeyApp, please distribute this to
a bigger group of people. So it’s giving you complete control
over the distribution of your mobile application. So that’s distribution. HockeyApp is really we acquired
HockeyApp like two and a half years ago I think. And then we acquired Xamarin
less than a year ago. I think we acquired
them back at build. So I always joke that Microsoft
just bought mobile dev ops. We literally just bought
all the pieces we need and we already had the main core of it, VSTS, and now we literally have
from beginning to the end. We have Xamarin inside of
Visual Studio for the developer. We have HockeyApp to distribute it, TeamServices to version it and
to build it. And then everything else you need
in between, Xamarin, Test Cloud and everything else to get you
a full mobile dev op stack, which is really cool stuff. Release management, this product is
the one that I was talking about that we acquired when I joined. I attached myself to this
product when we bought it. I literally wanted to
become an expert in it. Because as I said earlier, I knew the value that it
added to our pipeline. I started presenting on this
product, and I honestly believe risk management is why I stand here
in front of you here today. Because I obsessed over
this particular product. And I’ve seen it mature and
grow into what it is today, and I’m very proud of the product
that it has turned into. It literally was the missing
piece that made team services and team foundation server
everything that a company needs. So what I’m gonna here, is I’m
gonna take you on a tour of it. What’s funny is, is that it’s so
similar to the build, that I won’t have to spend
a lot of time on it. Because we tried to
make our build and our release very, very similar, so
that when you’re familiar with one, you’re automatically
familiar with the other. You don’t have to
learn something new. It’s not a new user interface. It’s the same look and feel. It’s the same user interface. It’s even the task that
you were using in build, you can now use in release as well. But the reason that it’s
a little different, I’ll point those difference out for
you. So let’s go look at the differences
between build and release. So if you go back to our build
summary, like I said before, again, I like the fact that I don’t
have to jump all around. I don’t have to go to
a different web site. I can actually just go to
my summary of my build and use that as my jumping off point to
all the other value that is inside of Team Services and TFS. And if you’re using TFS 2017,
it almost looks exactly like this. It’s like seeing double, right? The difference is that update
Team Services every three weeks. We update Team Foundation Server
on-prem every three months. So that’s the difference
between the two products. So if you don’t see it on-prem yet,
but you see it in the cloud,
wait about three months. And we’re gonna package it up, we’re
gonna push it down as an update, and then you’ll get those features. We also have a website that you can
go to that’ll tell you exactly when those features are coming out. We are trying to be as transparent
as we possibly can at Microsoft. So we’re an agile shop,
we are very transparent. Our road map is publicly
available on our website. You can see exactly when those
new features are coming and when they are coming
to the service and when they are coming to
the on-prem product as well, okay? So what I’m going to do here is
I’m basically gonna come down and I can see from my build that there
is a deployment that has already started and that the first deployment
section of it was successful. So what I’m gonna do is go ahead and
click on the Release-1211-01. And now it’s basically bringing me
to a similar dashboard that you saw on build, but this is for release. So if build and release are so
similar and they use the same tasks, why do I need them both? And that’s a really
legitimate question. There are two concepts that release
adds that build does not have. The first concept is an environment,
right? Is a logical grouping of assets or resources that define dev and
define QA and define production or stage one or stage two or stage
three, however your pipeline looks. Build doesn’t have that concept. Build downloads code,
it compiles it, and it’s done. Release has to then take those
binaries and deploy them one after the other automatically for
you in environment and environments. So that’s concept number one that
makes build different than release. As you can see here I
have three environments. I have a dev, QA and Prod. Dev has already been deployed
19 hours ago successfully and I can go back in and
I can look at the logs of this. Just like build, and
I’ll show this in just a second. I have a series of tasks that I’ve
selected need to happen to make sure that you actually deploy
my application correctly. This is actually not only deploying
the front end using HockeyApp. But we have Docker
containers involved in this, we have SQL Server inside
of Azure involved in this. This is an entire solution
being able to be built and deployed as a unit. So that’s why you’re seeing things
in like DACPAC deployments. How many of you guys
are SQL Server developers? Anyone work with SQL Server? How many of you know
SSDT stands for? Only a couple of you guys, right? And that’s the bad thing. SSDT stands for
SQL Server Data Tools. Go search that as soon you leave
the room if you don’t know what those things are. Because what I was able to do is
change the scheme of my data base. It produced something
called a DACPAC file and then I gave that DACPAC
file to release management. I can now put it in and
SQL Server I want and say go make that SQL Server
look like it’s suppose to. It writes all of SQL for
me at run time. No more me writing alter scripts. No more me trying to figure out,
I gotta concatenate my changes with your changes and make sure that
we do all the changes correctly. Nope, all that magic stuff
happens for you automatically. So SQL Server Data Tools plays
really, really nice with our release and our build process, so
definitely take a look at that.>>Question.>>Sure.>>[INAUDIBLE]>>Sure, so what I’m doing now,
that’s a great question. So the question was, I see you
have three environments but we might have four at our company or we might want to add another
environment to our company. How can I do that to
this particular pipeline? So what I’ve done is I’ve switched
over from the summary view of an existing release that was running to
our edit view which is like, okay, I now wanna edit an existing build
definition or a release definition. As you can see,
this is where I identify the Dev, the QA, and the Prod. And before QA and Prod, I might
want to add a staging environment. So what I could do is I want
to clone this environment, call it whatever I want,
Sam Guckenheimer, we’ll move Sam and put me in here instead. So this is interesting. This kind of helps me talk into
the second thing that makes release different than build. What I’m typing right now is the
second concept that makes release different than build. The fact that I can
actually put people or groups as approvers before or after
an environment has been deployed to. Right now these are what
we call pre-approvers. Let’s imagine a story where I am
the QA lead for an organization. So I own the QA environment. And I don’t want every CI build,
which can be happening every five to ten minutes,
to be pushed onto my QA environment, because I’m in the middle of
testing the current release. If you do that, I have no idea what version of
code is on my QA environment. And every time you
pushed a new release, I’d have to start testing over again
because I don’t know if you’ve invalidated any of my test results. So what I would do is put my QA lead
as the approver of that environment, and say, if and
only if that person says it’s okay, are the tools allowed to deploy
inside that particular environment. So this is where you’re able
to kinda put the brakes, and put the control. Human beings should never, ever,
ever deploy software, right? Never send a human being to
do a machine’s job, period. But there are times when human
beings need to be involved in the deployment. And this is how we allow
them to be involved yet never touch the zeros and
ones that get deployed. This is just me saying, hey, I’m
about to go touch this environment. Is it okay? It is okay, great. And this can be a group of people. This can be several individuals and we have different rules on
if it’s approved or not. So now all I can do
is to simply say, I would like to put myself in
here as an approver, okay. And now what I’ve done
is I’ve created a copy of that environment and I can just
drag that environment up to here. And I can call the stage and
now I can be able to go and change these tasks to then go and then target whatever it
is I want them to target. So the machine name’s end stage
would be different than they were in production or maybe
the configuration of the database or the passwords might be
slightly different. That’s were I would be able to
do in and adjust those values. I would click on, for
example, the database server. In here you can see the server
name happens to be a parameter. So what I can do is simply
say on a staging environment, I want to go configure my variables
such that the name of the server for that particular one might have the
word Stage in it versus the name QA. So that’s how I would be able to
add additional environments and have the configuration be
changed by the tools, right? If you’re an ASP.NET developer, how
many ASP.NET developers do we have? I love ASP.NET. How many of you guys have ever
rushed in, in a hurry to change a web .doc config and
screwed up your entire server? Everyone, raise your hands again,
right? Cuz you’ve all done that, right? Because we like, my God and QA the database needs to be
a different connection stream, or [INAUDIBLE] needs to be different,
let me go in really quickly and change that. And there’s a couple
things that can happen. The best case scenario is that you
leave off like a angle bracket and you get the yellow screen of death. That’s the best thing
that can happen, right? The worst thing that can happen
is you’ve put in the wrong connection string. So that your dev is now pointing at
production, or vice versa, right? Horrible, horrible things can
happen when you send human beings to do a machine’s job. We can do all of that
tokenization stuff for you. So if you’re web.config needs to be
changed we have techniques in our release system that will actually
change your web.config for you so that human beings
never ever touch it. But we understand values
need to be different from one environment to the next. Does that answer your question? Perfect. So it’s a very flexible system. And the two concepts that make
release different than build are environment and approvers. You put those together, and now you have a really powerful
system where you can build a really elaborate pipeline. And as you can see here, I am
deploying a database with DACPAC. I am deploying the website using,
this is a ASP.NET core website deployed to Azure SQL
and to Azure App Service. What’s really cool there is Azure
App Service has this concept called deployment slots. If you’re not familiar
with deployment slots, they allow you to do a zero
downtime deployment. If you’ve ever deployed
IAS website before, you use a copy of a file
called something offline. Takes the file,
takes the entire website offline so that people don’t get a 404,
but they get a site that says, hey, we’re updating it right now. You go and
you copy all of your files there. Then you take that file down,
and the site pops back up, right? But at some point in time, there’s people not being able to
do what they wanna be able to do. With deployment slots, as you can see what I’m doing
here is deployment slots, is a slot is basically a version
of your website in front of your actual production website. Where you can take you time and deploy there without taking
the live site down at all. The live site is still there, people
are still doing their transactions. I take my time, I deploy all
my code to the staging slot. I can even test against
the staging slot before the production
site is even affected. Then when I’m ready,
I simply say swap them. The IPs just swap,
there is zero downtime. Your users never know that they
have just gotten a new version of your software. And that’s what I’m doing there
is I’m basically stopping a slot, deploying my software there,
firing the slot back up, making sure it’s good and then I’m swapping
them right in front of my users and they have no idea. When I did this demo in New Zealand, people were using the app while
I was deploying it on stage. Right, so I changed the database
right from underneath them. And no one had any hiccups,
no errors, no nothing. So really, really cool stuff. And obviously,
I was using Docker as well. So one of them’s a front end, Docker actually has a web service
running inside of it for me. And I just threw that in there cuz I
wanted to make the most complicated scenario I could to prove that I
could do Docker, I could do Azure, I could do databases. I could swap slots, I could deploy
Mobile applications, bring it. Whatever you want to deploy,
wherever you want to deploy it, our tools are actually ready
to help you deploy that. That same list of tasks that I
showed you earlier is the same list of tasks that are available
to you here as well. So anything that you can do and build, you can do in our
release system as well. So release management is, again,
it’s the crown jewel in my opinion. It’s the part that made our
tools really, really great. And i just saw what we’re doing
within the next release and you’re gonna be very, very excited,
about what we have there as well.>>[INAUDIBLE]
>>We actually do have the connect demo. So James and I run a conference
in November called Connect. We had this bike sharing
app that’s a sample app, that entire app is in GitHub. Right, so you can actually see that. This one is not but
if you Tweet at me, hey, Donovan, can I see how you did this,
I’ll open it up for you, for sure.>>[INAUDIBLE]
>>The source code is in GitHub. So the source code for
the projects themselves, that’s a really good point. So you’re saying, but what about
the release definitions and the bill definitions? How do I set that stuff up? Now that is not there, it’s documented on how you would
go in and click through this. There’s another product that
I’ve been playing with but I might actually have time to
play with and show it to you. It’s called YO team. It’s a Yomen generator to
where you just [INAUDIBLE] type the word YO team and say I
would like an ASP.Net application in Team Services with
a full devops pipeline. And then I go and
do all that stuff for you, right? So the tool literally just goes in. We’re adding mobile to that. And we also have a product called
mobile sinner which James gonna talk a little bit about. It’s basically gonna take everything
that I’ve shown you today. All right, cuz I’ve shown you CI,
I’ve shown you hockey app, I’ve shown you test cloud. And it’s gonna take all of that and
put it behind one face for you. That way you go, hey, I would like to create
an app that looks like this. And then it does all that for
you again. So you would be able to
take our bike sharing app give it to Mobile Center,
it will provision the Mac for you, it will set up your CI for you. It’ll set up your release for you,
and you literally don’t have to do anything but
say that’s the app I want to build. So yes, it’s coming,
it’s in preview right now. All right so,
that is Release Management. So any other question
over Release Management? One more before we go.>>[INAUDIBLE]
>>Yep.>>[INAUDIBLE]
>>Okay, great, so as of 2015 Update 2, this Release Management,
I believe, is on-prem already, okay? If you upgrade to 2017, it looks
identical, it’s ridiculously good. When I was working on yo Team, I wanted it to work against VSTS and
TFS. So I had to install TFS,
which I hadn’t done in a long time. But after I installed TFS 2017
once it’s running it looks exactly like this. It’s amazing.>>[INAUDIBLE].>>All of it, yup, everything. You get the same build, you get the
same release, you get the same task, it’s amazing, right. It’s just three months behind. Like, package management,
I’m not sure is on prem yet but, package management is just one
of the features that we have. In this tool set, but the build and
the release that’s already there.>>I have another question.>>Sure.>>[INAUDIBLE]
>>So the question is is there a way
to import XML builds into here? So where are you building
them with today?>>[INAUDIBLE]
>>Yeah, but I don’t know why you’d have to then,
unless they’re XML based builds? They’re XML based builds, gosh okay. There’s no port from XML based
builds to our new build system. But we still support
a XML based build system, so there’s no reason for
you to have to port them. Yeah, if you upgrade,
they just still work. We even support them
inside of our XML. So if you have XML based builds,
you don’t have to port them. They are just gonna
continue to work. But obviously, you see some of the benefits
of this new build system and you might wanna move them over. But unfortunately, I don’t
know of way to just say, hey, take that XML build and switch it,
it’s so drastically different, right, the technology. Anymore, all right, so
we’ll go back to the slides here. I think we’re gonna be
able to do a lot of Q and A here in a second anyway. So we talked about releasing and the fact that we can do
different environments. I even showed you how to add
an environment very quickly. Two concepts are environments and
approvals. So continuous monitoring,
this is where we have to back and decide did we deliver value. If you added a new feature to your
mobile app, no one’s using that new feature, you did not deliver value,
in my opinion. All you did is you copied
a new version to the file, no one’s using it. But you can’t just guess. You need to have telemetry. You need to have numbers. You need to have metrics that say,
did we or did we not deliver value? And that’s where HotKey app and
Xamarin Insights come together. Those two products allow you to
have custom telemetry that says, did someone click that button,
right? When they went to
their shopping cart, how many items were
in the shopping cart? What was the quantity of the dollars
and, if they abandoned it, was there something we could have done to
make them go back and buy that? Should we have sent them
an email with a promo code in it, things like that. Those are the types of experiments
you can run if you’re collecting telemetry. If not, you’re just guessing. I think people are using it,
i heard through the word of mouth. I saw someone tweet about it, so
someone’s using it, no no no. I wanna know do we deliver value,
and that’s telemetry comes in. But it’s more than just
about monitoring telemetry. It’s also about monitoring crashes. Team services is a 24 by 7 service. And we have to keep it running 24
hours a day, seven days a week, 365 days a year. We have a lot of telemetry that
will actually let us know something is happening before you know
that something is happening. And that allows us to make
sure that we are able to keep that service running. And keep a really high level of
customer satisfaction because we’re able to start seeing that telemetry. So monitoring is more than about
that I just deliver a value but do we have a problem
out in production? Did we just ship a version that’s
causing people’s phones to crash and how quickly can we go back in and
fix that. Cuz you don’t want the first time
that you know that your app is crashing to be an email or a complaint or
a one star rating in the store. You want to know ahead of ahead of
time so you can be proactive and go back in and start fixing that. I’ll show you how we can do
that with HockeyApp as well. So HockeyApp gives you
monitoring of the sessions, how many people have downloaded,
what versions, how many crashes you have
in each particular version. And even gets people the ability to
log those bugs directly from within the application, so they don’t
have to have An extra effort, they don’t have to go somewhere
special to go log these problems. And actually put a bug in this
application just so I can crash it and show you exactly what that
experience looks like as well. So let me go crash my mobile app, which is a weird thing
to say during a demo. And [LAUGH] so here’s exactly how
we can report that crash back to the users and stuff. So if I remember correctly, if I go
to try to create something here, and I click on Cancel,
it’s just gonna crash my app. So the app just blew chunks,
unhandled acceptation. Now when I start the app
up again as a user, what happens is that
they detect that hey, you didn’t quit correctly,
would you like to send this report? I’m gonna ignore this one here. So it says hey, would you like to
send this report to the team so that they can actually
go back in and diagnose this and
fix this for you as well? I can say send a report. And what it’s doing now
is in the background, it’s emailing a crash
dump to HotkeyApp. And that HotkeyApp is able to
use the symbols that I have, and symbolicate the stack trace. And let me quickly diagnose
what caused that person to file the crash, what file they were in,
and let me go back in and try to make a fix, and then push
that through the pipeline as well. So if I go back over to
the HotkeyApp, which I should still have up here, you can see that I
have all these different crashes. And as a matter of fact, one of
these crashes should be from today. So when I was in the speaker lounge,
I actually crashed it a couple times to make sure that everything
was working correctly. And this is a matter of fact,
this one says 12:20. As you can see, it’s 12:21. I don’t know if you can
see my clock on there. So this is literally
the crash that I just did. It’s already in HotkeyApp there so
that I can go back in and start looking at it. Another thing I wanted
to show you is that this one has a status of open. And this one has
a status of tracked. The difference is is that
when this first one happened, I’m able to connect
HotkeyApp to Team Services. Remember I said Team Services
has bug tracking and all that kind of stuff in there? So literally I was able to say hey,
I want you to take this crash and create a bug inside of Team Services
for me so the Dev team can see this information without having
to come to HotkeyApp to get it. So now there’s a bug inside Team
Services that I can go back in and fix, and I have access to all this
information inside of here as well. So let’s just go ahead and
look at this particular item. You can see that every single
time its been crashed. If I go in here, you can see I have
a null reference exception here. I can see how often
it’s been happening, so I can see how bad of a problem is
this, how frequently are the users that are using our application
actually being affected by this, what OS it’s been happening on. And I can go back here and even see
a stack trace of exactly where I was in the code when this
exception happened. Because this is really
important stuff. Cuz we’ve all gotten that bug
report that we can’t duplicate. And we’ve set break points
all over our code and it’s never where we expect it to be. Now I know at least where
to set my break points. I have some idea where in my
application the problem is, so that I can go back through there and
try to figure out what was going on. So this is like, again,
incredible information, especially in
the mobile marketplace. I think that’s the most fierce
market that we have right now. At any given time there’s at least
half a dozen apps doing the exact same thing in the app
store at any given time. Which means if you crash my phone,
I am very unforgiving. I’m going to uninstall you,
give you a one star rating and I’m going to install
your competitor instead. And then your rating is
screwed forever because I decided to get upset at you,
because you crashed my phone, and I have so many other options. If you’re the only option,
your quality could be in question, I’d have to grin and bare it. But when there’s half a dozen, two dozen, solitaire apps out there,
crash me once and see what happens. I’ll be playing someone else’s
solitaire before the plane takes off, right? That’s the world that we live in. So you gotta make sure that if
stuff like this is happening, you are able to respond to it
as quickly as you possibly can. Continuously deliver value, right? That’s the goal here. Now, HotkeyApp goes a long way
of making sure that we have the ability to diagnose
these problems for you and send the information
over to our Dev team, and wire this up with the tools that
our Dev team’s already using. So, if you’re using Team Services,
they already talk to each other for all that information as well. So what did we get? So I went through that a lot quicker
than I thought I was going to. Make sure you start with a foundation inside of a good
source control system, right? If you’re paying for
Git, stop paying for Git, we give it to you for free. So if you’re paying for GitHub
Enterprise, if you’re paying for any type of Git Repository, we give
you the exact same Git for free. Everyone can go to
VisualStudio.com right now and create an account absolutely for
free. There is no credit card,
there’s no dollars and cents, just go create one and you can
start doing exactly what I did. You can start creating builds,
you can start checking in codes. And you and four of your buddies
can just jump into that account for absolutely $0 and 0 cents and
start using that, okay? Now the larger your company, we already start charging
the sixth guy, right? But the first five guys,
absolutely free. If any of those five guys
have an MSDN subscription, they’re extra free. They’re like double free. Cuz we don’t count them against
the five that we are going to start charging you for. So you and five of your
buddies all have MSDN already, no one’s paying for anything. You could add five more
guys who don’t have MSDN, have a team of ten for
absolutely $0 and 0 cents. And again, stop paying for
Git Repos. It hurts me when I
hear people paying for Git when we give it to you for free. And so,
all we want to do is obviously give you automated builds that you
can build anywhere that you want. Our build agent, a guy got it
running on a Raspberry Pi. Literally, anywhere
you wanna be building, we can build it there for you. Please remember that Microsoft
is any language targeting any platform, okay? That’s really, really important for
me to make sure that you get. And I think I will have time, so
on that note of any language, any platform, let me see if I can fire this
thing up here for you real quick. Can you guys see that okay? So I’m gonna type in yo team. So I was in a meeting
with Scott Guthrie. Scott Guthrie is one of our fearless
leaders, and he says, you know what? I just want to be able to
type into a command line, have an entire pipeline done for me. I don’t want to go clicking
through the user interface. So okay, I think we have
the ability to do that. Why do we have
the ability to do that? Because everything that I just
showed you inside of Team Services has a REST API backing it,
everything. Same thing with Mobile Center. They actually have to write the API
before they’re allowed to write the UI, right? To make sure that
everything can be automated to any extent that you want. So what yo team is asking me now is,
where do you wanna go? TFS or Visual Studio Team Services? Cuz I can take you to both. So once you upgrade to 2017,
you can do this, okay? And it says okay, great. I need to know where you wanna go. And one other thing I’m gonna do
here, so I wasn’t planning on doing this but I’m gonna do it now, is
I’m gonna load up this little file. This is my little secret to all
those who want to do presentations. What you want to do is create
something called AutoHotkey. So now I should be able to do stuff
like, say I want to go to my demos. And then in a second here it’s
gonna ask me for my token. And watch this. I’m gonna type a really
long string here. That’s AutoHotkey for all
the presenters in the room, right? Download that, you can tell
it to type whatever you want. You just give it a key shortcut,
and it types it for you. So what it’s doing now is, it’s actually communicating
with my Team Services account. It says, okay,
I know you wanna go to my demos. These are all of the agents
that I found inside of your account for you. And I see there’s one
called Default, Hosted. We not only have Hosted, if you notice at the bottom,
we have Hosted Linux agents as well. So again, I’m kind of deviating
a little bit from mobile, just talking Dev Op’s all up. If you wanna bid on Windows boxes, you don’t even have to
install our agent anywhere. We have, in Azure already, Windows
machines with our agent on it just waiting for
you to give them something to do. Our customers said we also
want to do this on Linux. So if you look at the bottom,
it says Hosted Linux agent. So now we have Linux machines
in Azure just waiting for you to give them somthing to do. So when you create your free Team
Services account, you get these two pools absolutely for free just
waiting to do your builds for you. If you need Macs,
things get a little bit different. Team Services,
you just stand up your own Mac. We give you what we call
one private agent for free. So stand up your Mac or your
Mac Mini, put the agent on there, register to them, and then you have
one like mine, it says Macs on it. Absolutely $0, 0 cents. Now if you go to a Mobile Center,
we’ll do the Mac part for you. So you don’t even have to worry
about the Mac at that point. So let’s go ahead and do default. And then this is where
we’re starting to grow into different languages here. If I wanted to do ASP.NET core,
if I wanted to do Node.js or Java. I’m working with teams out there. I don’t know PHP, so
that’s why PHP isn’t in the list. These are the three languages I knew
well enough to where I could put into the tool when I wrote the tool. If you know PHP,
this is completely Open Source. Go to GitHub, search for me,
you will find this application and you can add PHP to it. I will help you build the pipeline,
you help me with the language. I want Go in here, I want Python,
I want everything in here. Because what I’m gonna do for you is
build the entire pipeline for you. So now we’re gonna say
let’s just do node.js. And I want to called it nodeDemo. Now I even let you choose,
do you want to go to Azure or do you want to go to Docker? And eventually I want this to say
AWS, I want it to say Google Cloud, I want it to say
wherever you want to go. I want you to be able to just
choose this is where I want to go. And what we do in the backend
is we built the build and the release for you. Wired all the up to your target and all you have to do is push the code
into wherever you want it to go. So let’s just go to
AzureApp Service. It’s now querying and saying okay,
if you want to go to Azure, let me go see all the Azure
accounts that you have access to so that I can then go ahead and
wire one of those up for you. And now it’s basically saying
do you plan to do development on this machine? If so, I’ll go ahead a run Bower for
you, and MPM, and all the other tools you need to
reconcile all your dependencies. I’m not gonna do that now, so
I’m just simply gonna say no. What it’s doing now is it’s going
off and it says okay, great. I’m gonna go to your
Team Services account and create you a team project. I’m gonna then go in there and
create you a Git Repository. I’m gonna then go ahead and
create a CI build. I’m gonna create a continuous
release definition for you. I’m gonna wire it up into Azure, and
I’m even gonna give you a sample application that all you have to
do now is push into your repo, and all that stuff just
lights up automatically. So what I’m gonna do here is
just go ahead and log in.>>Is there any way to get around
this project as long as you’re using the same machine?>>Yes, when you’re using Git, you can fire up what they call
the Git Credential Manager. To where you log in once and it
will remember that for you forever.>>This is insane.>>[LAUGH]
>>[INAUDIBLE] [INAUDIBLE]>>Multiple times. So make sure that you upgrade
to the latest version of Git, cuz the Git credential manager is
part of the latest version of Git. So just go to normal git-scm.com, I
think it is, or org, whichever one. Just download it and install it, and you’re only
gonna get challenged once. And it’s gonna store
your credentials, and from then on it’s gonna be great.>>[INAUDIBLE]
>>It’s absolutely for free. It’s absolutely for free. Cuz trust me, I feel you. So let me type in this big crazy,
Password I have. Hopefully that went in correctly. So what it’s gonna do now is
it’s literally cloning my repo. And then it’s gonna go ask and
start to say, hey it looks like your repo’s empty. Don’t worry,
I’m gonna put some code in there. And it’s doing all this,
stuff for us. We’re adding mobile to this,
experience as well, right? So, you’ll be able to say, hey, I wanna a do a Xamarin
forms application. Fine, choose Xamarin.Forms. We’re gonna basically build
everything for you, so that you don’t have to do any of
this stuff yourself, any language, any platform. And that’s the reason I wanted
to show you this real quick, is that we have Node in there,
we have Java in there. We can go to Docker,
we can go to app services. Whatever you guys are wanting to do, we’re actually here trying to make
sure we make it easy for you. You never have to see the user
interface, if you don’t want to. It basically does everything for
you. So while that runs,
I’m gonna go back over to my slides. But I wanted to show you that. Cuz when you asked the question,
are the build definitions and releases in there? And the answer was no,
now they are, right? This is the tool that puts all
that stuff in there for you. So I think I have a node. No. No demo. Where’s my node demo? There you are. So I’ll just do a git push. So it already did a local
commit to my repo of the code. So all I’m doing now is pushing
it to In my local repo, and now I’m just pushing
it to the remote. And there’s a CI build
actually already running. Let’s see if this is on there or
not. But I’ve been also working
on- 13 minutes left? Okay, I’m gonna tell you just
to do something else for you here real quick. How many of you guys
are PowerShell junkies? Any people like PowerShell? Do you like PowerShell? All right, so I’ll give you a second
on my next pet project here. So I like PowerShell too, especially
now that it runs on Mac and on Linux. Who knew it was open source and
worked on Mac and Linux? You guys? So you can run PowerShell on Mac,
and you can run PowerShell on Linux,
as well. So what I started working on was
something called TFS PowerShell, which allows you to basically
do anything that you can do from Team Services from a PowerShell,
as well. Which means you can even further
automate some of the stuff that you want to do. So if I do an import module here,
and the modules’ name is team and if I do a get
command of module team. Just give you some idea
what’s available to you. So you can basically go and
queue another build, check the status of a build, approve a release and all that other
kind of stuff that you wanna do. This will be open source
here in a couple of days. I’m still polishing the code. Once it goes open source,
you gotta make it look pretty right? Can’t let everyone know all
the nasty habits that you have. So I’m polishing it,
making it look really good. So I can open source it and you guys
make you become a genius when I program but it’s getting there. But this version right here allows
you to get all the projects and get all the builds. And if I get get-TeamInfo, it’ll allow me to see
what account I’m already. So great, I’m already
attached to that account. So if I do get-Project here,
it’s basically gonna go and list all of the projects
that I have inside there. And you can see there’s a new
node demo project there. If I set this as my default project
I can now do things like get build. And when I do a get build, I should see that a CI build
automatically running. So if I do get build, That’s the build that was just queued,
cuz I checked in my code. And as you can see,
the code is already complete. So now what I should be able
to do is call get release, and I should see that there’s some
releases running as well. So this release is the release
definition that was queued by the build, thanks to the fact
that it did the commit. So I didn’t even leave
the command line. I was able to create a project,
create a team project, create a build definition, a release
definition, an entire pipeline, and actually trigger it all. And now with PowerShell, you can be
able to monitor where everything is actually going inside
of a PowerShell. And this works on Mac, it works on
Linux, and it works on Windows. Yo Team and
PowerShell works everywhere, right. So the only reason I
showed you all this, is cuz I said the words any
language, any platform, and I’m trying to make sure you guys
understand that I’m serious, right? This is not just playing around. All right, so any language,
any platform, I think, I hope you believe me now. [LAUGH] We can do any language,
any platform.>>You said yo Team is on GitHub.>>Yes, so I can show you that. So you don’t even have to
go to GitHub to get it. So if you have Yeoman installed,
you can just type yo. And then what you’re gonna do is, it’s gonna ask you to
install a generator here, and just search for the word team. And a couple of them
are gonna come up. You’ll see that there’s yo Team,
yo TFS, and yo VSTS. Yo Team is a successor
to the other two. I wrote Yo VSTS. People wanted it on prem, so I wrote Yo TFS,
realized how similar they were. And then I basically made Yo Team. And Yo Team is a lot
better than the other two. Cuz when you write it for
the third time, [LAUGH] yeah. Okay, I don’t make the same mistakes
I made the first two times, it’s much, much, much better. So if you’re interested,
I would just install You Team. Don’t worry about the other two,
you don’t need them, okay? They’ll be deprecated soon. But it is also in GitHub, so you can
see all the code how I wrote it and everything, okay? So yes, it’s there for you. I don’t need this anymore as well. So basically, DevOps is gonna make
your life in mobile easy, right? And Microsoft is already here at
every aspect of the dev ups pipeline to make your life easy. From development,
which James will show you later, from continuous integration,
continuous delivery, from monitoring,
from distribution to testing. Microsoft is here at every step of your mobile
development to get you there. From Git or Team Foundations
have a version control, build on Mac, Linux or PC, automate
on thousands of physical devices. Distribute using
HockeyApp over the air. Monitor crashes,
analytics and telemetry, and even collect feedback
from your users. This is all enabled for you. We’ve tried to think of
everything we possibly could. If we are missing something,
I’m @DonovanBrown on Twitter. I’m serious as a heart attack,
James. If I don’t know the answer to
Xamarin base, you’re gonna see James get added to that conversation,
the next thing I type, right? So please come back in here and
play with this stuff. We’re really excited about what
we have here at Microsoft, and hopefully you are too. So please,
at least go give it a shot. And if you aren’t satisfied, that’s
where you need to reach out to us. This is not the Microsoft where
we’re in an ivory tower and we don’t talk to our people. We are actively on Twitter,
we’re active on social media, you can also use a website
called user voice. So you can go to use your voice,
give us an idea. Have your buddies vote it up,
and when it gets to the top, our product team starts
to take a look at it. If you have a strong
Twitter following, you can do all kinds of damage. I do it all the time. If I want something to be
at the top of user voice, it’s only one tweet away. [LAUGH] From being at the top,
we’ll use our voice. So just use that power that you have
in social media to get your ideas to us here at Microsoft, as well. So feel free to go and
play with this stuff, we have a lot of information for
you as well. And I am now ready to answer
any questions that you have on pretty much anything DevOps related,
mobile or not. Thank you, so much for joining me.>>[INAUDIBLE]
>>Great question. So how do we take something
that’s hosted in the web, and deploy it to
something that’s on prem? That’s the question, right? That agent that I described that
can run on Mac, Windows, and Linux can be installed anywhere,
including behind your firewall. Which means you register the agent
behind your firewall to us out in the Cloud. And it’s just a conversation
where he says, hey, Is there anything for me to do? Yes there’s something for you to do. And then on your network,
behind your firewall, it can do whatever it needs to do to get the
stuff deployed to your iOS server, without ever seeing the web. We had customers who said, we wanna
use Release Management in the cloud, before it was on the on-prem
product, but it’s there now. But we don’t want a single zero or
one of our IP to see the Internet. Like, okay, fine,
that’s exactly what we did. We had Team Foundations
that were on-prem, talking to Release Management
in the cloud, with an agent behind their firewall. Not a single line of
their source code or anything ever saw the Internet. But we are able to communicate
to that agent and say, hey, it’s time for
you to go do your deployment. He says, okay, the code that I
need to deploy is on this side of the firewall, so
let me go grab it from this server. And the server that you want me to
deploy it to is also on my side of the firewall. Let me go to this IIS server and run whatever commands I needed
to to deploy that application. So the deployment completely
happened on your network, behind your firewall, but
was orchestrated from the internet.>>[INAUDIBLE]>>Yes, it’s awesome,
it’s just ridiculous right? Yeah, the answer is yep. [LAUGH] So,
what other questions do we have? One more?
>>[INAUDIBLE]>>Good question. So the question was with
HockeyApp synchronizing or pushing data to Team Services,
how does that information come back. It is actually synchronized, right? So there’s a two way communication
between HockeyApp and Team Services, and it gets better and better
because we own HockeyApp now, right. So they are literally a team and
Redman, right next to the team that
works on Team Services. So that communication just
gets better and better and better as time-
>>[INAUDIBLE]>>Well, what will happen is they’re gonna be able to get another update,
like I did, that says that says, okay, these are the bug fixes
that are in this particular fix. So what I was said in my example,
was I added middle name for you. You don’t just have to take
an arbitrary release from us. You’ll be able to see
in the release notes, that these are the bugs we fixed, these are the features
that we added. Because we want you to go and focus
on that when you play with it this time, to verify that this
bug has actually been fixed. Does that answer your question? All right, cool. I saw someone, right here.>>So [INAUDIBLE] preauthorization
for a release for the [INAUDIBLE]?>>The approvals?>>Yes, does that have to
be [INAUDIBLE] to that?>>Good question. So the question is, do you have to
be a certain license level to be an approver on a release? The answer is even
a stakeholder that’s free, can actually be in there, right. So yeah, you do not have pay to
be an approver of a release. And the approvers can be
individuals, or they can be groups. Which is kinda cool cuz it
gives you some flexibility. The last thing that you want is
your QA lead to go on vacation and then all of your releases stall cuz
the one guy who could approve them is on vacation. So what you can do is you can
actually put a group there called QA leads or something like that. Anyone in that group has the
authority now to push that release to the next stage. So it’s like, basically
everyone gets a notification, first guy goes in and
says, yep, that’s good. It goes ahead and moves forward and
we can also go back in and say, I don’t have a group but
I have this five individuals and I want one of these five to say yes. Our tool is flexible
enough to do that. You can also say I
want them in order, which means notify
the first guy only. If he or she says no, don’t worry
about notifying anyone else, right? Because they’ve already gotten a no. We don’t need to go and ask anyone
else what’s going on there. So really flexible in what you can
do from the approver aspect and you can actually have
approvers before and after, which I’m not sure was really clear
cuz you specifically asked about pre-approvers, which is great. Which is, the tools asking
permission to touch your environment and once you give it,
it’ll touch your environment and then it’ll stop before it goes
into the next environment. It can actually have another
approver that says you have to give us approval to leave
this environment. So I’d use the QA lead
again as an example. If the QA lead says yes,
you can go into my environment and then he tests it and finds lots of bugs, you don’t want
that going to the next environment. So you would also put them
as the post approver and the tool will simply wait for
them to finish all their UI testing, all their manual testing. And say, is it good enough? And you can say nope and it’ll
just kill the release right there. And it won’t go into staging,
it won’t go into production and wherever else you want
it to go as well. So, yeah, I think that’s one of the
really cool parts about our release management is that ability to
orchestrate all the approvals. We have a lot of our,
Our companies and our customers are using
Octopus Deploy. And someone tweeted at me the other, that’s a real enterprise
deployment system. I was like, yeah, you know what? Funny thing is,
it’s better together. That deployment system
works best when it’s actually underneath release
management giving you that level of approval that I just gave you,
right? So instead of having to choose one
or the other, you can actually use them together and get a really,
really sophisticated solution where we give you the approvals,
we give you the workflow, we give you the traceability, we
give you the continuous integration. But you wanna do the actual zeros
and one copying with Octopus Deploy, knock yourself out, rIght? We can intermingle every part of our
system, even though I believe that you should be using one vendor
if you can get down to it. If you just insist on using
Jenkins for whatever reason, you can actually remove our build system
and put Jenkins in its place and still use everything else that
I mentioned to you today. All right, so if you already
have an investment in Jenkins, don’t think, my God,
I’d love to use Team Services but I gotta get rid of Jenkins
before you do that. No, you don’t. I actually have a blog
post on donovanbrown.com. Type in the word Jenkins and it’s a
blog post that says, how to replace our build system with Jenkins
if you’re already using Jenkins. Cuz I don’t want you to believe
you have to use it all. Obviously, I want you to,
but you don’t have to. We just lost some lights over here. Go ahead.>>How would you deploy to
AWS native PaaS services?>>How would I deploy to
AWS native PAAS services? I’m gonna answer this
in a very generic way. Replace AWS with anything,
no, literally, with anything. I’m not saying with Azure. [LAUGH] That should be my answer but
it’s not. Replace it with anything
that you want and then my answer will be this. Is there a command line or
a REST API that will allow me to achieve whatever goal it is
that you want to achieve? If the answer is yes,
then the answer is yes. The reason why is because one of the
tasks that we have in our toolbox, out of the box, you don’t have
to install any extensions, is the one called command line. When I first saw that task, I thought it was
the Windows command line. It’s not, it is literally any
command line which means Bash shell, or if you’re on Linux or
Mac or command or power, whatever you wanna run, we’ll run
any arbitrary command that you want. So when I was playing with Google, what I did is I installed their
tools onto my build agent. Which now gave me a collection of
command line tools that would allow me to deploy it to Google. And all I did is told my
build system at this point, now that I packaged up my website, go call this command out into
Google and give me the status back. So if you can do it
from a command line, we already have the task there to
go perform against AWS or Google or Bluemix or whatever cloud
provider that you want. And also, if there’s a REST API,
cuz some of them are saying, no, we don’t have any command line but
we have a REST API you can exploit. Well then you can write
a PowerShell script or a Node.js script that will go
call that REST endpoint for you, get back the status, and
report it as part of your build. So my answer is show
me a command line and I’ll show you how to do it in our
build and our release system. So that’s a generic answer to yes,
right? Cuz I know they have the tools
that we need to to be able to perform those. Now there are also, if you go to
our Marketplace and you type AWS, there are extensions out there
already that are basically making it even easier, so that you don’t
have to write the command line. There’s a task that
you just configure and it will point you to whatever
cloud you wanna go to. Great question. What else do we have?
One more in the back.>>So with the [INAUDIBLE] test, can you tell it to, [INAUDIBLE]
to work for [INAUDIBLE].>>If there’s a command line or a
REST API to that tool that you just described, local or
otherwise, the answer is yes. If there’s not, then we’d have to go
and look at a case by case basis.>>[INAUDIBLE]
>>If we can script it, the answer is yes. I haven’t tried that. I know what you’re asking is like, I have an individual item that I’d
like to run automated tests on as part of my build up that’s
not in the test class.>>[INAUDIBLE]>>I know some that are. All right, you don’t know any that
are but I know some that are.>>[INAUDIBLE]
>>That’s fine, that’s fine. So my answer for you is
the same as the answer was for this gentleman here. We’d have to figure out
a way to script that. If I can script it, then I can
run it as part of my build.>>[INAUDIBLE]
>>Do you know the answer to that?>>No.
>>Okay.>>[LAUGH]
>>Yeah, I don’t know the answer
to that either.>>[INAUDIBLE]
>>All right.>>[INAUDIBLE]
>>Yeah, and if you cannot wait->>[INAUDIBLE]>>All right, so this is where I pimp one
of my favorite partners, which is Perfecto Mobile,
who already has Windows devices and ties into our pipeline,
just like Xamarin Test Cloud. So if you don’t wanna wait for
us, whatever that date is, go to Perfecto Mobile right now and you
can run exactly the same thing, not only against Android and iOS, but
also against Windows phones as well. But I know it’s coming.
I mean, how can they not? I just don’t know when either.>>Is it an operating system thing? [INAUDIBLE] There’s some
big names of operating systems updates that come out.>>Sure.
>>Windows 10 also, it’s one of the [INAUDIBLE].>>All right, cool deal. I’m over time guys,
so thank you so much. I wanna get out of
the way of the next guy. See you later.
>>[APPLAUSE]

Leave a Reply

Your email address will not be published. Required fields are marked *