So let's look at what collaboration
source control and continuous integration and
delivery,
which we refer to as CICD,
looks like with the Power Platform in
GitHub. So, here's a Power App that our
team has been building to track time
off requests. So I can see my current leave requests
as well as the status of them,
my leave balance, company holidays -
but a feature request we've been frequently
getting is I can filter my leave request
by pinning and approval states,
but not declined.
And so we could just edit this app in
production, republish the changes,
but it's likely that we're gonna want
to create some traceability for these
changes- and have them be tested prior to
just deploying them straight into production.
And so this is really what GitHub is
great about. So we're going to use
GitHub to see what it might look like
to kind of work through this entire workflow
from kind of requesting this feature to
actually building it out with the Power
Platform to deploying it into production with
GitHub actions.
So here we are,
inside of GitHub and we're looking at
the repository for my time off app,
and so - think of a repository as just
a giant folder that's going to track
all the changes that I make over time.
And you can see here within these folders
there, there can be sub folders,
there can be files,
And so what we can do with GitHub is
we can represent our Power Platform solution
as a GitHub repository.
Another cool thing about GitHub is
we have this concept of branches and
branches or just copies of my main folder.
And so,
within this,
I can create branches for things like
my main branch,
which is typically my production code.
I could have a development branch,
and in each of those branches,
I can collect multiple changes.
So say I'm working on 1.0 release.
I can put all those in a development branch,
track them over time,
and as it when I'm ready to release,
I can actually take all of the changes in
that branch in that folder and bring them
into the main directory with something called
the pull request.
So we'll return to GitHub later,
but right now I want to show what it
would look like to actually create a feature
request. So we'll come over into issues
and GitHub has really great integration for
things like project management -
and so I can come in and I can create a
new issue,
and I'm gonna say add declined filter
capability.
And we'll go ahead and submit that
new issue,
and I'm gonna go ahead and assign myself
and I can leave comments,
I can collaborate with other members of
my team, I can do all that right here.
And all my issues will show if I go
to this issues tab,
I can do things like add milestones,
labels, that sort of thing.
So there's a lot of really cool functionality
I could do for collaborating with others
inside of GitHub.
Okay, so we've created this issue.
The developer building this app sees
this issue.
Let's go back and actually create the
fix for this issue and see what it looks
like when we wire that up to CICD
with GitHub actions.
So here we are inside of the Power Apps
and Power Platform Portal again and you
can see here:
I've opened the time off request solution
and the solution is just a container for,
a lot of Power Platform things.
So in this case,
it's a canvas based Power App.
But I could also put things in here like
Power Automate flows.
And so, in this case,
I've gone ahead and added my leave request
to this solution and what we're actually
gonna do with GitHub is - we're gonna
represent the solution in source control.
So that's what we just saw when we
were over at GitHub
when we're looking at the the structure for
our repository,
we saw solution folder,
and so that's just a code representation of
what's inside this solution.
You see,
I also have different environments that
have created, so I have a development environment-
this is where I'm actually making my
changes on my app.
I have a build environment.
This is where I might be testing the
changes that I've made.
Then I have a production environment and
this is the environment where the apps
live that my end users they're actually
using with the Power Platforms.
So let's go ahead and actually update
this leave request app.
So you can see here we have pending and
approved.
We don't have declined.
Let's go ahead and actually make that
change. So, lucky for me as the developer,
it's a super easy change.
I'm just gonna come in here and I'm
gonna add filter declined.
And you can see that the UI updates we
have declined.
I'm gonna go ahead and save... and I'll
come back over into here and I'll publish
these changes as well.
And now you can see that all changes are
changed and published.
So if we come back over to the solution and
I refresh this,
it says one second ago,
just gonna refresh to make sure - so
13 seconds ago,
my leave request tablet app was done.
And so we're in our development environment,
but what we actually want to do is
we want to take this,
pull this into source control.
We're going to create a new branch with
these changes,
in GitHub, and remember a branch is just
a different version of main folder that
can changes the changes.
So let's jump over to GitHub
and here I am on this GitHub actions tab.
We used issues earlier, we're using Git-
Hub actions now,
uh, these actions are just things that
we can do,
they are work flows that I want to do
inside of GitHub
so based off something that happens in
this folder,
I may want to trigger some action.
So in this case,
I may want to trigger the ability to
go and get the latest solution from the
Power Platform environment and bring that
into GitHub.
So let's go ahead and do that now.
So we'll go back over to actions,
and I'm gonna click on this export and
branch solution,
and we're actually just going to view
this workflow file.
And the really cool thing about our
GitHub actions integration is that I
don't have to really do anything to
actually make all of this automation work.
We've gone ahead and defined that for
you - so you can see here
there's different kind of steps and
jobs that happened within this,
and we'll see what this looks like in
a second.
But there's not really any code I'm
writing here.
All I'm doing is specifying some property.
So, for instance,
my environment URL or my username
and my solution name,
so there's really not actually much
I'm having to do as far as the developer
to actually get this integration
to work. So let's go back to the GitHub
actions tab.
I'm gonna select exported branch,
and we're gonna go ahead and run this
workflow so I'll click run workflow... and
you can see that the exporting branch workflow
solution is now showing as queued.
We'll click on export from dev,
and our workflow is going to start and
run through a series of actions that's
going to take my solution from the Power
Platform -
bring that into GitHub by creating a
new branch -
put those changes in that branch and
we'll be able to track all the changes
that are making to that solution inside
of that development branch without affecting
that production folder that we had that
main folder inside of GitHub.
And so what this does is creates a
really nice traceability for all the
changes that I'm making with the Power
Platform.
And as you can see,
it's going through and running those
steps that I actually had,
in that workflow definition file
that I just showed,
and so it's going to run through each
of these,
and when we're done with this,
what we should have is a branch that
contains my changes.
Okay,
so now our Git-
Hub action has completed -
so let's return to this code view and
this should be unchanged.
You see, 22 minutes ago,
five hours ago,
two hours ago,
nothing has actually changed right here.
And that's because remember,
we were exporting to a branch.
So you see now, when I click on this branches
button, I see time off request.
And so if I click on this,
I can see the most recent change was
31 seconds ago.
I can also come over here into commits and
I can see all the changes that were made.
So if I want to go back and roll back
to a particular change,
the really cool thing about putting this
into source control is,
we have that traceability of all the
changes that made. And so we can see
that this branch is one commit ahead of
me, so that just means is one change
ahead of me.
So we'll just go ahead and create what's
called a pull request.
And really,
a pull request is just the request to
pull the changes that are in one branch
into that main branch for production.
And so I'll go ahead and I'm gonna say
fix issue number three because that's the
issue we're fixing.
I'm going to create a pull request,
and I'm gonna go ahead and merge this
pull request.
Great. So our issue has been fixed,
we merged the changes,
and if I go back over to my code,
you'll see that the latest change was
one minute ago.
So now what we've done is we've taken
the changes that were in this branch and
brought them into the main branch.
And so this might be where I would deploy
to an intermediate environment for testing.
But we're just gonna assume that we've
already done that because I'm a great
developer and we don't need to test
things.
So what we now want to do is deploy this
to production and the really cool thing
I could do with GitHub is I can create
releases so I'll come over here and
create a release,
and it's likely when you're building an
app, you're not republishing for every
single little change you're making,
right? Your coupling feature changes with
bug fixes and kind of doing that as
a stable release to a user.
So you're probably putting many of
these changes together and then releasing them
to users.
So in this case,
I'm just gonna version my release 1.01
and I'm going to say,
Hey, we added the decline filter capability
to my PowerApp.
And so, like,
this might be where I would do like a
whole release notes section on what actually
happened here.
Supposing I made multiple changes.
So go ahead and publish release,
and something really cool is gonna happen.
So you can see here.
I have latest release added decline filter
capability to my PowerApp.
I can download this so I have this really
nice traceability.
But if we go over to actions,
we'll see that something is actually kicked
off. We've kicked off this release solution
to prod GitHub action.
And so what this is actually gonna do
is this is going to take all of my
solution that's represented and Git-
Hub right now in source control.
It's gonna package that up,
and it's going to deploy that to my
production environment that we talked about
earlier within the Power Platform.
And then my users are actually gonna be
able to use that production app that
I've made with these changes.
And so what we've done is we've kind
of flowed this application from development to
this
test environment.
And finally,
now we're moving into the production environment.
Okay, so our released.
solution to production
GitHub action has completed.
And if we click over here,
we can see that it goes and publishes
this is to my environment.
So we jump over to my production environment
so you can see him now switched to
my production environment.
I'm gonna go ahead and refresh and
you'll see modified 31 seconds ago.
I haven't actually gone in and modified
this in my production environment,
but what we've done is we've taken that
app that was in GitHub and pushed it
directly into my production environment from
GitHub - pretty cool.
So - let's go ahead and run this application.
And so we'll go ahead and log in as an
employee and you can see that have a
bug I need to fix.
I should file that and GitHub issues.
And now we have this decline filter, so
that's awesome.
So what we did is we just showed the
power, no pun intended, of GitHub and
the Power Platform together.
So first we represented that Power Platform
solution that contained my app as a
repository in GitHub.
This gave us traceability for the changes
we're making with change tracking.
Next, we logged an issue with our Git-
Hub issues for the app developer.
After that,
the app developer made changes in the
development Power Platform environment without
production affecting production users
represented those change in branching Git-
Hub using GitHub actions.
We then tested those changes and then
we deployed them into production using
another GitHub action.
And so this shows just how easy it
is to deliver application lifecycle management
traceability would change tracking and
CICD with the Power Platform in
GitHub