So (lets simulate that) my last release created a production issue.

The SCPI interpretor times out regularly, when used from one of the available PC clients.

Maybe the job optimisation in the ADC task takes away free time from the UART RTOS task?

It's a simulation for the purpose if this blog. This didn't (but could) really happen.

Goal:

• fix a bug in production code - master branch
• use the Eclipse Git plugin to manage the development (I try to introduce something new in each post. Previous ones used the command line).
• use a feature branch to work on this (we did that in the previous posts too)
• use GitHub Issue to manage the development task (again a repeat of the previous post)
• use GitHub Pull Request to manage the approvals, reviews and merge the hotfix into master
  This time with a Draft pull request early on - again something new introduced here. And keep adding commits to that pull request until done
• properly link the pull request to the issue.
  I forgot this the previous time. Let's do this now, and have the issue automatically close when the pull request is approved .
• Use tags to flag this as a bug.
• Project Board automatically done for us. No developer and approver actions needed to give a project management view.
  This is the same as the last one, except that the issue now automatically jumps to the Done lane when all approvals and reviews are in.
• In the next blog: sync development with this change, to avoid regression issues later on.

The Branch strategy was discussed in a previous post: Firmware Version Control with GitHub part 2: Branch Strategy for Bug Fixes.

I'm applying it now, step by step:

Create production issue

In GitHub, create the issue to report the production bug:

Because this is a bug, I assign the existing bug tag to the issue - and later to the pull request too.

Assign the owner and project, to get it on the board.

Create a Feature Branch in Eclipse to work on the breakfix, with the GIT Plug-in

We used the command line in the previous posts. Many IDEs have a plug-in though.

Here, I'm using the Eclipse GIT plug-in in Code Composer Studio. TI's Eclipse based IDE.

You can create a new branch by right clicking on the project, then select Team -> Switch ...

Then push that branch to GitHub so that your work is tracked.

The parameters are pre-filled if this is an active Git repository.

note to self: maybe later write a post on how to initiate a repository. But there are many around that are very clear ...

You can see in the project view (left) and Git Repositories window (bottom right) that the active branch is highlighted.

Eclipse and the plug-in do a good job to show what branch you are currently working in.

Create a first Commit and a Draft Pull Request

Here, I'm introducing something new. You may or may not like it. It's not essential, but flags early that reviews will be pending soon ...

Make an edit. Any edit will do, but I usually enter a comment in the readme or in the "what's changed" file. And save it.

Not everyone is a fan of storing what's changed info in the project sources a s a text file. They prefer to source it from the bug system.

In this example it doesn't matter. We just want to have a first file change, so that we can commit it and out branch becomes "dirty".

Update the readme to flag what we're working on. Then use the Eclipse plug-in to commit and push upstream.

It's the excuse to get that feature branch dirty so that we can immediately start a draft pull request... (controversial )

The pull request is made just like in the previous blog. But against the master branch. I'm fixing a production defect.

Next to the green create button, there's an arrow. Select that and mark that you want a Draft pull request.

Set the tag to flag it as a bug.

A draft is just like any other pull request, but it will not be submitted to the approvers. You can keep on working.

Any new commit + push you do will be automatically collected into the draft.

Why, Jan? We didn't use it in the previous flow.

Well, there are 2 possible advantages:

• you give the reviewers an early heads-up of the work on the horizon
• you can link the pull request to the incident. When the pull request is being approved, the issue status hikes along.

Once the draft is there, I can link the incident to it (I forgot this in my previous blog)

The draft pull request is now visible on the issue too. And it's moved to in progress.

The board now shows the pull request and the issue cards, both in progress. Project manager will be delighted.

Fix The Bug in Eclipse, using the Git Plug-in for the Commit & Push

Now, actually write the fix, committing and pushing to the feature branch.

I'm again using the Eclipse plugin to do this.

In the spirit of Git and Agile: commit and push often. Develop iterative until the bug is fixed and tests pass.

Once that's complete and I'm confident that the bug is fixed, it's time to submit for approval:

Submit the Pull Request

In GitHub, review the draft pull request and make it a firmed one.

You'll see that our subsequent commits were automatically added to the draft pull request.

I use my admin rights again to override branch policy (explained in the previous post). Normally done by the code reviewer and branch owner ...

... and also delete the - now obsolete - feature branch:

Now, this should (and will) pull everything to complete (issue, pull request and both Project cards), just by accepting the pull request.

Work Done for the Bug Fixer - but there's a next step

And yes, that works .

So approval of the pull request has closed the issue it was related to.

But if we fix something in production and don't apply that fix to the development team, we set ourselves up for a future drama.

The next deploy from project to master would overwrite our good work and we'd have the bug again.

So the solution is to send these changes to the development branch.

I will now create a task for the development branch owner to sync this break/fix into the development branch.

Handling that task is for the next post ... The circle of life