Update to blogging workflow
In this post, I describe updates to my blogging workflow.
When I first started this blog, I followed a simple master push workflow. This was easier to simply make an edit to a file and push the changes to see the result live. This approach treated the entire anmsh.gitlab.io repository like a regular software project. It was effortless to write something and see it live without much ado.
After all, how much overhead does a single developer need?
As the repository started growing in size, it become unwieldy to mix blog post drafts with design changes and experimental features. So I decided to use a better workflow to manage writing content and adding technical or functional features easier.
I came up with the following model with two types of branches.
Few Permanent branches
- Master branch where I write new posts, renew ssl, update project meta information (README, plugin, CI) or any other emergency fixes
- Design branch for significant behaviour, style or structure modifications to the blog.
Several long running feature branches
These should be short lived ideally, but the fact that I am the only developer on this project, would not afford me as much time I would like. As a result, working on a feature is the hardest thing to do as compared to making a design update. Hence the long running branches. In terms of their utility, these branches are still short-lived.
This worked until now. These days I am using a merge request workflow in my work projects. I thought about giving the merge request workflow a try for my blog.
To accommodate this, I need to adjust the above model a bit by adding a new permanent branch.
- Drafts branch for writing new posts and raising merge requests for publishing posts.
The branching strategy, roughly speaking, becomes the following.
Whenever there is a design change or a new post
- Raise a merge request.
- Reverse merge master into other permanent branch(es) frequently
Whenever there is a new feature
- Merge into design branch for testing with current design
- Raise a merge request
- Reverse merge master into other permanent branch(es)
For this to work, I have protected push to master, even from the Maintainer (me). This has an added advantage of not running the pipeline each time a careless push makes its way into master.