posts

posts.md

+++ title = "title" date = 2022-06-02 description = "A gist test"

[taxonomies] tags = [ "tag1", "tag2" ] projects = [ "project1" ] +++

Here's the content!

wallop-logistics.md

+++ title = "" date = 2022-06-19 description = "Explore the cavern of logistics behind Wallop"

[taxonomies] tags = [ "CI/CD", "github" ] projects = [ "Wallop" ] +++

Abstract

As Wallop nears its first "release", which is compromised of ONLY the Engine component, it's becoming necessary to talk about the logistics around the project.

Currently there I haven't been following any standards and obviously if you sow chaos, so shall your harvest be come reaping season.

So, it's time to get cartographical and map out some ideas about the CI/CD, Versioning, and Workflow I'd like to use for Wallop.

*: I'm by no means whatsoever an expert at any of this stuff. I'd be more than happy to hear out any suggestions.

Workflow

The overall Workflow is comprised of branches, github actions, and special labels for issues and pull requests.

Branches

I could probably explain this with one single word: Git Flow.

But instead I'll opt to detail the process here.

So we'll operate across numerous branches to isolate work units. Two of which will be used to centralize the code base, the difference between these two will be in the assumed stability of the code base as far as each branch is concerned.

develop will be our source of truth for ongoing development. This branch stores the continued efforts, and will not be considered stable by any means whatsoever.

main serves to balance the see-saw of stability out. It'll be the responsibility of this branch to maintain the code base in an ideal state of perfect stability.

hotfix/ branches recognize that, just as in physics, strictly practically speaking we can't assume the world is in an ideal state. There will always be a tiny (hopefully no greater) bit of friction, and hotfixes branch out from main or release to patch mission critical bugs before being merged (via PR) into both its originating branch and develop.

feature/ branches: okay, so the stability see-saw is now slightly trending towards stability with the addition of hotfix branches. So it's time we introduce a little more chaos into the mix.

For every feature/enhancement we'll branch off of develop and make the changes into a feature branch and merge it (via PR) back into develop once the work has been done and tested.

release/ branches: Alright so I feel like we've gotten to know each other pretty well and I want to level with you. Though balanced, we have one fatal design flaw in our see-saw. There's no connecting rod between each side of it yet.

This rod is introduced through release branches. A release branch is merged off develop and contains an update to the project ready to make it to the stable branch of main.

When in a release branch, the code base is ironically said to be in a prerelease state. Hotfixes may be created from and pushed into release branches as necessitated from testing or bugs found in main.

When it's good and ready, we can weld this connecting rod into the other side, and perform a pull request to get the release merged into main. We should also merge this branch back into develop to ensure any patches made to this release also make it back into develop.

Actions

Merging into develop

The first action we will discuss will be one operating on the completion of a pull request from a feature branch into develop.

The relationship between feature branchs and issues in github should be 1:1. Thus when a PR is made, it should refer to the issue or feature it's solving. The same applies to hot fixes being merged in to develop.

A github Workflow will trigger once this work has been merged to do a couple of things:

1. Increment the version number(s) as appropriate
2. Build and deploy a nightly version.

Bear in mind that this Workflow should not trigger for merges from release branches.

Merging into a release branch

Similarly to when work is merged into develop, when work is merged into a release branch its version should be incremented as appropriate and a pre release deployment should be made.

An important thing to note however, is that only big fixes and small patches should be merged into an existing release branch.

Merging into main

Once a release is complete and has been merged into main, a Workflow should trigger a build and deployment of a full release off main.

Hotfixes merged into main should increment the version and also trigger another deployment.

Labels