6cb552cdcc746e6cd6f9c5a099cbe942c0653dba — Tim Hårek Andreassen 3 months ago d7a47f2
feat(blog): Add new post "My ideal development workflow"

Signed-off-by: Tim Hårek Andreassen <tim@harek.no>
1 files changed, 85 insertions(+), 0 deletions(-)

A content/blog/2023-06-06-my-ideal-development-workflow.md
A content/blog/2023-06-06-my-ideal-development-workflow.md => content/blog/2023-06-06-my-ideal-development-workflow.md +85 -0
@@ 0,0 1,85 @@
title = "My ideal development workflow"
description = "How I like to work in order to get things done."
tags = ["100 days to offload", "thoughts", "git", "devops"]

This year I've started a few project both during my spare-time, but also at
work. At work I've been very fortunate to be the tech-lead for the projects I've
been assigned to where I get to try new things and find an optimal workflow that
works for both my co-workers and myself.

## 1. Foundation

I like to start with setting up a new project using git, at work we use GitHub
so I usually create a new directory locally and run `git init` and use
`gh repo create <project-name>`, and if it's a personal project I usually host
it on SourceHut. Then I start by setting up the neccessary tools that we're
going to use for the project, this varies on a project-basis.

After all the boilerplate is setup I like to use my time to write up a proper
`README.md` so that my co-workers and I know what this project is about and how
to get up and running.

## 2. Automating deployment

I don't like to deploy manually, it's fairly error-prone and it's easy to forget
a step or two. So I try to automate this as much as I can, here my tooling
varies based on the project, but I mostly use [SourceHut builds][srht_builds],
[Buddy.works][buddy] and [GitHub Actions][gh_actions]. But in order to automate
the deployment-process I like to write down everything that needs to happen,
this I do in a simple Markdown-file with some code blocks with comments for
myself. And I use this file to see if there are any steps that I can remove, do
earlier or later, and see if there are some stuff that needs explaining.

## 3. Workflow

When I work on my personal projects I barely use PR/patches since I'm the only
contributor, but at work I make PRs all the time. And we like practise [trunk
based-development][trunk], which means we use short-lived feature-branches made
by a single person. I use feature-branches for myself as well so that I can have
a clear log of every change and merge.

And here it's good to have a up-to-date changelog, ideally after each
feature-branch I will update the changelog to describe what I've changed. Here
it's useful to practise good commit hygiene, I like to use [conventional
commits][con_commits] so that I know wheter a commit was a new feature, bugfix
etc. That makes it easier for me to write and keep the changelog up-to-date.

## 4. Actual deployment

So how do I deploy to production and a staging environment? Using tagged commits
with [semver][semver] and pushes to the main branch. For production for example
pushing a commit that has been tagged with `git tag` would result in push to
producion. And for staging it would simply be pushing and/or updating the main
branch on the remote host. By using semver it makes it easier to see in the git
history when and where changes have been deployed, and it could also tell your
co-workers or end-users what version they're currently using.

And to make tagging more useful I use the `-a`-flag so that I can add additional
notes to the tag. And here I like to copy-paste the changelog for the current

## 5. Maintain the README

During development it isn't unlikely that something in the workflow, setup etc.
will change, so it's important to update the README regularly in order to save
time and frustrations. I like to add notes like **"Things to know"**, why did I
end up using this package or plugin, why is the project structured the way it
is. And always try to write as precise as possible, if something needs a lot of
explaination maybe something has to change elsewhere?

## Final thoughts

This is my ideal workflow as of now, don't arrest me if I make any changes or
stray away from this workflow in the future 😅 I'm always trying to optimize my
workflow and find better ways to work with others and make everything as smooth
as possible.

[srht_builds]: https://builds.sr.ht
[buddy]: https://buddy.works
[gh_actions]: https://github.com/features/actions
[trunk]: https://trunkbaseddevelopment.com/
[con_commits]: https://www.conventionalcommits.org/en/v1.0.0/
[semver]: https://semver.org