One of the main reasons why so many brilliant hobby projects fall apart and never see the light is the lack of a robust development flow.
You came up with an interesting idea that seized your attention for a brief amount of time. During that timeframe, you laid down a prototype and made it work by cutting corners. You receive a shot of satisfaction, and then life gets in the way. You forget about that project for a while, and then, when you come back to it once again, you are present with the burden of uncertain plans, ambiguous code, and lack of willpower to sort it all. Plus, there is a new shiny idea that attracts your attention.
What helped me to break free from that vicious circle is a template that I now apply to any new hobby project, and that template drastically extends the longevity of the projects. If a hobby project ceases, then it’s because of some deeper intractable problems.
The best part of that template is that it’s easy to fire it up (can be done in under 10 mins for a fresh project) and it’s completely free and doesn’t require any specific bits of knowledge.
- Tasks manager for release planner
- Source version control
- Automated CI for tests and deployment
- Any new idea at first goes to Backlog (most leftish column)
- Then I decide what would go into what version by moving items from Backlog to a Version column
- When I’m ready to work on a task, I move it from Version column to In Progress Column
- When the Version column becomes empty -> I release the version Note that there’s no step that would move from In Progress to Done, that’s because it would be done automatically when you’ll merge your code!
Once I decided on the task, I move it to In progress column, and from the dropdown select Convert to issue
That would automatically create a branch from the master in which I can jump into to start working.
Once I commit changes into that branch, a button to create a Pull Request (PR) would appear on the project’s GitHub page.
But I won’t be able to merge the PR until all checks pass.
What checks you may ask? Well, that depends on your preferences. For me, I always include at least a basic set of tests to a code that I’m writing. Before the PR could be merged, all tests are required to pass. Your mileage may vary and you could only include a check that a project could be built, that at least would give you something that you could build on top of when you are ready to do so.
Also, you could set up Bitrise in such a way that on every new PR that gets merged, you would receive an invite to install a new build right on your device. Bitrise allows you to choose between a direct download link, a test flight update, or a custom solution. It’s extremely handy when you want to try out a new thing that you added in the latest PR.
After changes are merged, a prompt to delete the branch would appear. I’m always pressing that button since changes are already merged to the main codebase and most likely I would never come back to that branch again.
By the way, the task will automatically jump to Done once I merge the code and close the dedicated issue.
Another remarkable feature of Bitrise is that it could watch for Tags on your GitHub repo. That would come in handy when you’ll finish all the tasks in your Release column and it’s time for a new release.
So, when an app is ready for a release, I just take a commit that I would like to make a release from and tag it with a release name.
That triggers a workflow on Bitrise that would compile code and push it to the store. In the meantime, I could just make a new cup of tea while everything is taking care of.
It’s quite hard to grasp all the tiny details of this setup in the blog post, so if that post gets a meaningful amount of reactions I’ll make a video version that would guide you through the whole setup from a blank project on GitHub to a complete release workflow on Bitrise.
Feel free to connect with me on Twitter to be among the first to know when a new video or tutorial becomes available!