kalohq / dennis

[DEPRECATED] GitHub Release Automation Helper

⚠️ deprecation notice ⚠️

This project is deprecated. As part of moving towards a continuous delivery workflow, we’ve removed many features of dennis. It no longer does what the readme says.

If you want to take over the maintenance of the project, get in touch! 🖖

Dennis -- helping to release and ship it

Setup

• It's advised you use a cache directory so Dennis doesn't need to clone the repositories for every release.

mkdir -p ~/.dennis

• You may benefit from either adding a Bash alias, or from creating a one-liner script within your project, for running the releases

# If you're using Bash
echo "# Dennis release helper" >> ~/.bash_profile
echo "alias dennis='docker run --rm -v ~/.dennis:/git -ti -e REPO=<repo name> -e OWNER=<owner name> kalo/dennis'" >> ~/.bash_profile

GitFlow-esque Use Cases

You may run the release commands from any directory. Dennis maintains its own cache of cloned repositories, on its mounted volume.

Docker command

The command should always be run with these settings:

docker run -v ~/.dennis:/git -ti -e REPO=<repo name> -e OWNER=<owner name, defaults to kalo> kalo/dennis

which is why it's recommended either to create a Bash alias, or, if you have multiple repositories to manage, to have a script within each one of them.

Further down, we'll assume we have aliased the above options as 'dennis'.

Create and Release a normal (minor) release

# Step 1
dennis prepare --type minor --user <Github username> --token <Github token>
#
# ... QA cycle ...
#
# Step 2
dennis release --type minor --user <Github username> --token <Github token>

Create and Release a hotfix

# Step 1
# Publish a branch onto Github, make sure you created it from "master" and not from "develop"

# Step 2
dennis prepare --type hotfix --user <Github username> --token <Github token> --branch <a published branch name>

#
# ... QA cycle ...
#

# Step 3
dennis release --type hotfix --user <Github username> --token <Github token>

Extras

• You'll be happy to hear that dennis acts in an idempotent fashion, so he'll try to pick up where he left off if there was a partial failure previously, for whatever reason
• dennis does allow to override the version number and source branch from which the release is created, e.g.:

dennis prepare --version v53.69.999 --branch feature/please-avoid-this-dangerous-workflow

License

Apache 2.0. See LICENSE for details

dennis's Issues

Switch back to previous branch after release

🙈

Extend dennis to help with managing feature branches

In a quest to automate and speed things up (avoiding vital need for knowledge of process/implementation details) putting this out there for thoughts.

• dennis release *
  • IF pending pull requests into release branch [1]
    • bail
• dennis start feature <BRANCH_NAME> [2]
• dennis start fix <BRANCH_NAME> [3]
• dennis finish [4]
  • ask for details from QA.md [4]
  • automate things like a jira link from branch name
  • IF type="fix":
    • IF no hotfix release branch exists: [5]
      • rename branch to "release/0.0.x"
      • run prepare
    • IF hotfix release branch exists: [6]
      • create pull request into existing release branch
  • IF type="feature": [7]
    • create pull request into develop

[1] Extending the current script if there is ever a pending pull request into a release branch we should have to address that first before releasing.
[2] This currently would just be a glorified git checkout develop && git checkout -b <BRANCH_NAME>
[3] Again, just a glorified git checkout master && git checkout -b <BRANCH_NAME> but also distinguishes itself as a "fix" which allows us to do some clever stuff later. Here you "just want to get a fix out as quickly as possible" so you're thinking about it in an isolated box.
[4] This command, dependant on the type, can prompt for more details or open favoured text editor with QA.md to edit in the same spirit of git commit.
[5] Fix: If no existing hotfix release (0.0.x) branch exists then we will create it with prepare and push our changes to that
[6] Fix: If there is a hotfix already about to go out we may as well jump onboard and bundle our fix with it rather than have to wait (remember the fix was developed in an isolated branch from master anyway so it should be good to go by the time it hits a release branch)
[7] Feature: Opted not to provide the "get shit out quick so allow hopping straight onto a feature release" here as we should encourage everything hitting develop in a stable state. This simply creates a pull request into develop like we usually do with features and sets up correct tagging.

This is all, of course, used in conjunction with the standard prepare and release commands.

Maintain a release plan file whose contents get presented in the release PR

A release plan file similar to CHANGELOG.md should be support that contains a section for a release plan for the next release. The latest section should get presented in the next release PR

Check a hotfix branch is actually taken off master and not develop

Fix tagging so the release tag tags only the new things gone into master and not things in develop

Check if there is a demo in progress

The sales team have setup a new calendar to document whenever there is a client demo. During these times we should try to avoid releasing anything to production to prevent accidental mishaps.

Assuming a trivial GCalendar API we should get dennis to check if there is a demo in progress and block a dennis release. The user should be able to --force a release incase of real emergencies.

Feature request: Don't allow release of minor/major if there is a pending hotfix

I just accidentally released a pending minor version before a pending hotfix. oops! :(

Upon dennis release we should ensure that queued releases are done in order by warning at any attempt to release a version number higher than the smallest pending release version number.

Feature request: Post comment PR when it has been released

Currently I don't feel as though there is enough visibility to when a PR actually gets released to prod since there is an indefinite period of time from when the PR gets merged to when it goes out. It would be great if dennis could post a comment on the PR when a release happens.

Thoughts @junkafarian @chrisui @yannispanousis

Ensure release PR checklist is completed before allowing release

It is common that we will include a RELEASE.md file which contains a markdown checklist of release procedure steps. We should ensure that all items are "checked" before allowing dennis release to work. Again we should allow a --force opt-out.

Wrong version of PyGithub

At the moment Dennis installs PyGithub 1.26.0 which won't work. Had to use the lystable fork https://github.com/lystable/PyGithub

This issue can be fixed by PyGithub including @yannispanousis 's PR or just using the fork.

Check for local changes during preparation

Problem

I just prepared a hotfix branch not knowing that my npm-shrinkwrap file was different to that in master. When the branch was prepared dennis automatically committed my changes. :(

Solution

After creating a new release branch dennis should bail if there are extraneous changes between the new and target branch. We should be forced to acknowledge the changes being rolled into a release.

Only require “required” checks

At the moment we have one required check to roll a release onto master – the circle build. However, dennis determines whether the build has succeeded by the last build that came in, not by the required build.

In our case, the code coverage check comes in last – and that check which is optional. This blocks us from releasing in the tightest of deadlines, when we need to cut corners with testing.

Pull master locally after release has completed

Notify user if dennis version is out of date

• also just print the series of commands needed to update