Working on Bulba
I've gone through a few changes to my development setup, and also tweaked a few things on how I work on Bulba, so I thought I'd write about what developing Bulba is like.
Writing Code
When it comes to writing code, there's not many tools that I actually need. I use VS Code for my code editor (and built-in terminal), Todoist to track what features, and a browser to do all the admin work.
As for the tools I use in the terminal, I only require node and git, although I have oh-my-zsh as well for my own sanity.
This simplicity is what has allowed me to pretty easily configure a new development environment. As I'm now playing around with Pop!_OS (I'll probably go into more detail in the future), and it didn't take much time or effort to get things set up.
Tracking Features
When I'm working on Bulba, I'm typically working on one or two features at a time, depending on any dependencies or relations. But for the most part, every feature starts as a single task in Todoist, where I track the progress of each task using a very simple kanban board.
It has three columns: Ideas, In Progress, and Pending Release, which I guess are pretty explanatory. I went with a simple process, as I really don't need anything complex for how I work on this project. There are ideas that I may want to work on, the things that I am working on, and stuff that I've finished working on, but haven't released yet.
You could say that the Pending Release stage isn't totally neccesary, and I would agree. But I'm a very forgetful person, so I find it super helpful to keep track of the features that will be included in the next release. It makes it very easy to write the release notes.
Releasing Bulba
The way releases are handled for Bulba has slowly changed as I've progressed on Bulba, and I think I've found a pretty good spot between automating tasks and also having a manual process to write release notes and have a tiny bit of control.
For a few releases, I was doing it via the npm publish command from my local machine, but I also wanted to use Git tags to mark the versions, and then also create an associated release on GitHub with some notes. This got annoying after a while, and I ended up automating a small part of it, that now makes the flow much better.
So now, thanks to GitHub Actions, whenever I create a new release on GitHub, it will run a short script and publish Bulba to both npm and GitHub's package thing (I'm honestly too lazy to work out what this is, but it didn't require any work to also publish there).
So my entire release process is this:
- Update version in
package.json - Tag latest commit with version
- Create release from tag on GitHub and add some notes
- Bulba is automatically published
There's a possibility that I'll look into automating the version updating, but it's not exactly a cumbersome task to do manually.
Deploying Bulba
As you may have seen in the Readme, the way I personally deploy a Bulba blog (this blog) is by having a git repository for my blog content. And then on a Digital Ocean server, I pull the latest changes, run Bulba, and then I have a short script to move the outputted files to the correct place.
This is fine. But it's not as easy as it could be. And while I haven't looked into it that much, Digital Ocean has some very interesting support for static websites (Guide), where you can host your static content in a GitHub repository, and have your website automatically be deployed after changes.
I'm not sure if that's what I will use myself, as I've got a few more things on the server where I host this blog, but I definitely think this could work as the "recommended" solution. So watch out for more information on that.