Scenario:

• Developments for current cycle are finished (by the developer. That's me) and are available in my repo's development branch.
• All that code has already been tested, built (by the developer. That's me).
• All code has been reviewed and accepted, as part of the development cycle (by the development branch owner. That's me).
• Release manager (hey, that's me too) now has the task to collect all development and integrate it into the release. That's the master branch.

Tools I'd like to use:

• GitHub issue module to define the work item: create release
• GitHub project module to manage the work, with "automation"
• Git command line to merge the development code into the master code
• GitHub pull request module to accept that merge into the master branch

Goal

• a: have a process and tool support for developer and approver / reviewers
• b: have a project view of progress for the project manager, without the developer and reviewers ever have to do project management updates.

Step 1: Assign the work - create an issue

An issue can be a bug report, but also a task such as creating a release.

By assigning it to someone (hey, that's me again), and linking it to a project, you automatically get scrum / Kanban style functionality.

Step 1a: Review the project board

I want to use automation as much as possible. The project integration is supposed to give insight. Not give more work to the developer.

You can see that our board has one new card, in the To do lane. Let's just look, don't touch.

Step 2: Start working on the release

I have this issue open on my name now, with the project board reflecting this.

From the issue, we can flag that we're going to work on it:

Step 2a: Review the project board

As expected, the task has moved lanes.

Step 2b: Do the work - create a release pull request to merge development into master

Creating a release is actual work. We can change statuses and stuff, but that'll never get things done.

We need to make the hands dirty. In Git.

$ mkdir release20200509
$ cd release20200509
$ git clone -b master https://github.com/jancumps/msp432.git

I specify the master branch here, although that is the default branch.

I do it because in reality I automated this in a batch script with parameters.

So I can pull in changes from branch B into branch A by just defining the two branch names (+ the name of the feature branch I temporary create to support the pull request).

$ cd msp432
$ git merge development -m "sync development changes into the master branch"

$ git checkout -b release20200509
$ git push --set-upstream origin release20200509

Our release branch is now ready to be integrated into master:

Review the pull request content before creating it. You get an overview of all the files that changed, and what has changed.

Also check that you are actually pulling the correct branch into the correct branch.

In this case, the goal is to pull the changes from development (collected in temporary branch release20200509) into master.

Link the pull request to the project card. See next section - you only have to do this if you want to get a view of pull request progress on the board.

Step 2c: Review the project board

Because I selected the project in my pull request, a new card is created on the board.

You don't have to do this. If you just want to stick to one card to manage the issue, just don't add the pull request to your project.

But if you want to enable tracking of the approvals by the reviewers (hey, that's me) , you can use this functionality.

Step 2d: Flag that you've submitted the issue for review

You're finished with the work. You as developer (hey, that's me) can flag that in your issue.

Step 2c: Review the project board

Your issue card has progressed. Both developer and reviewer tasks are visible for the project manager (hey, all 3 me) on the board.

Step 3: Review the pull request

Here I can't show the full flow because I haven't set up a second contributor to review the pull request.

I'm using admin override to approve my own request.

GitHub makes this very clear by using bright red for all admin override options.

Let's set it to In Review.

Step 3a: Review the project board

Step 4: Approve and merge the pull request

In the real world an approver would be assigned. You can select one from all the repo members that have commit access to the destination branch.

In my case, I use the admin override to accept my own pull request:

The pull request card moves to done.

I always delete branches that have been accepted. Some platforms, such as Azure DevOps, allow that this happens automatically at acceptance.

Step 4a: Review the project board

The reviewer / approver tasks are done. The card moved to the done lane.

Now it's time for the release manager to update the issue.

Step 5: Release Done. close the issue

Totally optional, the release manager can flag that the pull request is reviewed and done.

In a work situation, I'd flag that it's been sent for review, just to keep the project manager aware.

The card will then show up in the relevant lane on the board.

What you have to do as release manager, is close the issue.

The acceptance of the pull request is automatically recorded (see purple label):

Enter a closure message and close the issue. You have finished the task. The release is confirmed and available in the master branch.

In a managed way. Goal a.

Step 5: Review the project board

This is what project board automation can offer:

Having a project view of the activities, based on real activities by the developers, release manager, reviewers and approvers.

If you've ever been in a situation where you have to maintain task status as a separate activity in a project management system, you may appreciate that,

if you define a repeatable process, you can have the status on the project board up to date.

Without updating project stats. Goal b.

The one that's responsible for the issue can manage all statuses from the issue (me ).

The one responsible for review and acceptance can manage all statuses by approving review and accepting merge (me ).

The one responsible for project management gets a real time view of everyone's duties (me too - there's no escape in a one person repo).

Comments and critique, as always, welcome in the comments. Fire away.