>> Welcome back to Less Code More Power.
Today we're seeing Part 2
of the Application Life-cycle Management episode.
If you didn't see Part 1, go see Part 1, then join us.
[MUSIC] Hello.
Welcome back to Less Code More Power.
I'm your host, Dona Sarkar and my lovely co-host is.
>> Sarah Critchley. Hey, everyone.
>> Hey. We're back with Part 2 of
our two-part series on ALM aka Application Lifecycle Management.
If you haven't seen Part 1, pause this,
go see Part 1. You're not pausing.
Go see it and then come back because
you're going to want to know what we said last
time so you can understand what we said this time.
So don't skip to the spoilers.
Trust us, you will not understand what we're talking about.
Today we're back with Phil and Marc talking about
how anyone in the world can
actually use ALM to do their work better,
not just traditional developers.
Phil and Marc, thank you for coming
back and joining us. We didn't scare you off.
>> Good to be back.
>> We're a little scared, not that scared.
>> Not that scared.
>> All right. Just recap for us Phil,
what you shared about; What is ALM?
Why would people use it?
What are some cases to make people's lives way the heck easier?
>> Yeah, last time we talked about
Application Lifecycle Management,
like how do you manage
the application as it transitions from
development to test and to prod.
Then over time as it keeps getting
upgraded and move to three different environments,
test and production as users provide more feedback and as
developers collaborate on creating it and maintaining it.
We talked about how to use
Power Platform solutions to combine all of the elements in the app
so that you have a package that's easy to move and we
moved a couple of apps, both CAT-themed apps.
We moved our CAT-themed apps between
test and prod to show the process.
>> So while we were
moving the CAT-themed apps, you were showing us,
okay, this app is built on Dataverse,
we're moving the tables, we're doing this, we're doing that.
The way to move it was packaging
up into a solution, which you could deploy anywhere.
We understand there's an easier way to do
this or there's a way that works for anyone in the world.
>> There is, yes. So we did everything manually before.
We packed it up in a solution,
we exported it manually,
we imported it manually, but there's automation that can do this.
Like here on my screen, I've got Azure DevOps.
If you haven't seen Azure DevOps before,
know that Azure DevOps is free for up to five users.
If you're using Power Apps,
this is available to you as well.
I have a DevOps pipeline created here and
I'm installing the Power Platform Build Tools.
Then I'm doing the same steps that we
did manually in the last episode,
but I'm automating it, I'm publishing customizations,
I'm exporting the solution.
I'm also running Power Platform Checker
to look for any issues in this.
That's something I skipped last time.
But we can enforce it here and that's
part of ALM and automating ALM,
is to make sure our processes are consistent.
That's one advantage automation gives us besides just making
sure that this moves without us having to do all these steps.
Then this last step here, we're unpacking
the solution which is just a zip file of
the app's configurations and we're putting them in source control.
Source control allows us to see everything that's in
the solution and track it as it changes over time.
So if we need to go back in time to
an older version we can do that.
As we understand the contents however,
we can also compare to see what's changed.
>> Just to make sure the audience understand right.
Once this is up, that's it, right?
It can then just be run and rerun and
essentially that's the foundations of the ALM process.
>> That's right. It could even be triggered to
Power Automate, it all comes together.
>> Phil, do we have to do it with
Azure DevOps, or do we have other options?
>> We have another option over here too with GitHub.
GitHub is another place we can keep our source and
GitHub actions allow us to do the same thing.
We can export our solution,
we can release it to prod,
all the same actions we did in DevOps,
we can do in GitHub as well.
>> I love that ability to use GitHub actions because
it's such a good co-author tool where you can say,
"Hey, we want to collaborate on this thing."
Whether I'm a citizen developer, traditional developer, whoever.
Want to collaborate on this, collaborate on the data,
collaborate on the app itself,
and then move to whoever's environment we need to move it to.
Sarah, I think this must be a life-changer
for you and your customers where you're building things for them.
>> So much.
>> Yeah.
>> Because the thing is it takes so much time.
The amount of time, I mean,
I've had to work late before when I've
been doing all this manually all the time.
Also, when people are joining,
everyone has their own process
and it's really hard to manage that.
So this really helps especially as an SI.
It really helps us to really say this is how
the best standards are
and we can actually bring our customers along with it.
I think it's the same as well if you're
working directly with the customers about being
able to really show them
those best standards as possible to make a repeatable process.
>> One of the things that we find is that
even being able to do these things that Phil has already shown,
there's still an additional learning curve
to doing it and doing it
well and doing it in a repeatable fashion.
So one of the things that we're doing as part of
the Power CAT team because we also
built something called the Center of Excellence Starter Kit,
is we're actually building reference
implementations to make going from
zero to ALM much more easy and much more productive.
I'm going to switch to my screen if that's okay.
>> Yes.
>> You're making it fun. You'll make an ALM fun.
That's what you're doing, right?
>> That's right.
The first thing that you're going to see
here is an application that we've
built that is actually doing quite a bit behind the scenes.
It uses GitHub behind the scenes.
It puts things into source control.
It does environment provisioning,
it does a lot of things.
But people don't want to have to
worry about doing that as a maker.
They just want to come in.
They want to do their work and they want to
move what they've built from DevTest to prod.
So this application is geared towards that persona where literally
all an end-user that
uses this application has to know is that they can come in,
they can request to create a new project,
give it a name, give it a description,
we're doing approval process behind the scenes.
They don't know who get's to flow approvals behind the scenes,
etc, they just know it goes through
the approval process behind the scenes.
At some point, an admin approves it or some approver approves it.
Behind the scenes, we provision Power Platform environments.
We set up a GitHub repo.
We deploy GitHub actions to the repo.
The maker then just gets an e-mail and says,
hey, your project's been approved, go do your work.
So they come in, they click "Open their solution."
It takes them right to their work,
they build-out in their solution.
They publish their customizations.
They come back to this app.
They say, "I'm ready to go to test."
They click a "Deploy" button.
They can pick where it goes.
Once it's gone to test, once all ready,
they can pick to move it to "Prod",
for example, on a different project.
Then all of you behind the scenes,
again, a lot of things happen,
including an approval process,
which includes looking at source code.
But again, the maker probably doesn't want to have to look at
the source code of their app because after all, this is low code.
But we're exposing the source code if you will,
or enabling people to put that source code and that archive of
source code somewhere so that
admins and professional developers can go look at it.
>> This is amazing. This is like, honestly.
>> [inaudible]
>> I feel like I needed this for my entire career.
>> The interesting thing is that if you give
this application to a professional developer
who's using a Power platform,
they're going to scream at you, right?
>> [inaudible]
>> Because they don't want all this stuff hidden.
They understand words like get, employ,
pull, request and commit.
They want to see the source code.
They don't want all the knobs hidden from them.
We built a completely different application
and I'll switch to that one.
>> [inaudible]
>> Over here, that is really geared towards advanced makers.
It really assumes you know what
solutions are and assumes that you know you're
getting your code into a Source Control System but it
gives that Easy Button convenience layer over all of it.
I'm a developer, I get a work item for the day.
Maybe it's been a couple of weeks since I've done some work and I
know other people on my team that have
been committing work to source control.
I need to go get the latest.
Well, we have an ability to go click "Import",
get the latest from source control into my environment
to build on top of the latest work from my collective team.
Once I've done that, I can come in here.
I can similarly open my application,
go do some work in it, make some changes.
Then I come back to this app.
I click "Push Changes. "
This just shows that Easy Button Layer over what Phil showed
you and if you actually look at
our pipelines, they're pretty robust.
They're actually the same pipelines that
this year we Starter Kit team,
use to do our ALM.
We're basically taking all of the work we've done
for ourselves and essentially making it an
accelerator for other people to be able to do what we're doing
without that huge learning curve that
it takes to get there. Does that makes sense?
>> Yeah. This is awesome.
>> Absolutely.
>> We also enable things like Pull Requests Writing.
I think where this starts to become very
valuable and I always say whether it's Low Code or Pro Code,
we've all painted ourselves into
a corner when we're building, right?
>> Yes.
>> Yes, Power Apps has this history
see feature where you can go back to a previous version,
but what's really useful is if you can go back in time and
see like the code and really drill down and narrow into something.
For example, if I pull up,
let's say this one right here,
I can actually drive into the Source Code for my app.
This code that I just committed,
I can come in and look at the solution as Phil was showing.
We are using this newly announced capability
to unpack Canvas apps as Source Code.
You can come in here, you can look at
the source for your Canvas app.
I can see that some changes were made,
so what is that change?
I can just look at a comparison.
I can see what happened from one point to the other.
I can put my code in.
This is my little safe space where
my incremental changes go and then I go,
''I painted myself into a corner?''
I go back to three [inaudible] before,
I see what I did there, I see the next one.
I copy and paste the code.
I put it in my Canvas app and I get
myself out of that corner that I painted myself into.
Even for low code folks,
having the access to
a source control system becomes really valuable.
For us to see as the CoE starter kit and
for more complex applications,
it gets even better because we do Pull Requests.
A pull request in simple terms is,
I want somebody to look at the work that
I've done in and approve that it's
high quality before I basically bring it into my main application.
We do those of things and if I look at
a Pull Request and Azure DevOps here, guess what?
We do things like builds.
None of the changes that a person on the CoE starter kit
makes goes in and is accepted until we do a Code Review on it.
The code has to build from Source Control,
deploy to a target environment, and for example,
if I look at one of these builds,
as Phil called out,
we're using things like Solution Checker.
I can actually see that, for example,
I added a screen into this application still named Screen one..
That same App Checker that you see in
the Maker Studio is now here for the code review.
I can say, " Okay, first of all,
it's not a good name.
Second of all, it's not accessible."
I can go and make those changes or I can tell
the person whose code on reviewing to go and make
those changes before we accept
those changes to go out into a test environment.
There's much more to how
this application works but it's really geared
towards that traditional ProDev Systems Integrator
who's using Low Code Technology and
really advanced complex ways and wants to have
that full end-to-end application lifecycle management process
they're used to just over the Power Platform.
>> Wow, well if you changed my life with the previous app,
you've definitely changed it with this one.
>> I know.
>> This is amazing.
>> Yeah.
>> I have just a quick question before
we then go ahead and summarize for the audience.
Marc, sometimes you can have
some different workstreams doing this kind of stuff.
Would the app that you just showed support that kind of stuff?
>> It does. The app has been written to be extremely flexible.
Unlike the previous app where we took
this principle of you want to guide people
down a certain path without exposing
all the complexities that are possible with the Power Platform,
we had a completely different philosophy
with this app which is to say,
we don't dictate anything about the ALM process.
We do some defaults around Branching.
But as you commit changes or you submit pull requests,
you can pick any Branch you want.
It enables to go to the far extreme of one developer
per environment doing small incremental changes
and committing often in submitting changes often,
to feature teams each working in
their own environment to hopefully people aren't doing this.
Like lots of people all working in the same environment.
We will support good practice and bad practice.
We will certainly, as we document
some of this stuff on docs.Microsoft.com,
we will share how we do Branch Management and merging and those
things to help people down a path of success versus,
maybe, introducing lots of
issues in their solutions
because they're all working in the same environment.
>> That's amazing.
>> Yeah.
>> Honestly. I think this has given the audience,
so much stuff to really get started with.
People who are going to watch this and be like,
where can we get this app?
Where can the audience go ahead and get started?
>> For the first app, it's available today, aka. msCoEstarterkit.
>> Yeah.
>> We'll provide links.
The second app is in private preview.
We plan on, or hope to go into public preview,
come right around at night.
If we aren't, if people are really interested,
DM me or hit me up on
Twitter and I'll get you into the private preview.
>> Brilliant.
>> Wow, that was amazing.
>> This is huge. I love that you thought
about all the Developers we work with,
from someone who might be just
starting off with Power Platform who needs to collaborate
and they may have never encode in their lives
or all the way to the traditional Dev who's
been living in a C++ world for 15 years and they're like,
''In fact, I need to see my
Source Code because I'm a control freak.''.
>> Right.
>> I do appreciate that you've
really gone to where the Developers are.
You're saying like, ''For
super familiar with Git and Pull Requests,
we're here for you but if you have no idea what that
is and you do not care, we're also here for you.''
>> Yeah.
>> Exactly. For customers
like Sarah has and customers like we have,
this is a huge game changer because you're not talking
to a specific department or another,
you're saying there's something for everyone.
It does not matter where they're starting off.
That is really lovely.
Awesome. Thank you so much both of you for being here with us.
>> Thanks for having me.
>> Thank you.
>> So audience, please get in
touch with Phil and Marc with any questions.
You see their Twitter handles and
these two are some of the best in the world at helping
people debug their thing and solve their problems
and we want feedback from you because based on feedback from you,
this is why we build products like ALM.
>> That's true.
>> Awesome. Thank you so much for being here.
Till next time. Let's Code.
>> More Power.
>> See you.
>> Thank you guys. [MUSIC]