The Problem
I have a ton of project ideas and concepts captured in notebooks, sketchbooks, and other paper-based media all somewhat well-organized (at least by my standards, if not my wife’s). Managing source files for my Maker projects is another matter. Until now I have been making backups intermittently at best, with the occasional file dump to my Google Drive account.
Last week I decided that this had to change.
Driving this decision were two things: first, building this site and second, my goals as a maker. Initially I started working on this site back in September because there had been a lot of buzz in the technical communication field about using Jekyll as a documentation tool, so I thought that creating a site about my personal Maker projects would be a fun way to learn. Slowly the site has come to mean more than that to me. I’ve not only invested a lot of (mostly enjoyable) time learning the technology, but I also realized that I’ve enjoyed getting back into the habit of writing blog posts.
The second factor is that earlier this month I officially set a goal for myself to focus on Maker projects that can become an income source. This is far easier said than done, but hey, picking a destination is an important first step in any journey.
Identifying these two factors has helped me reinforce the idea that my time is valuable and I respect that. Therefore it makes sense to back up both the site’s content and my Maker project code on a regular basis. While being more rigorous about copying files to Google Drive is certainly possible, it makes more sense to use a source control system to get the job done.
Requirements
Here’s what I identified as requirements for a source control solution:
- Git-based/compatible
- Cloud-based
- Secure
- Easy to use
- Minimum 10 private repositories
- Free (to start)
- Scaleable
- Reliable
Possible Solutions
The most popular option is the GitHub account I created, but have not used. Their pricing is based on the number of repositories, not users. Their first price point includes five private repos which doesn’t work for me because I haven’t decided what will work be public versus private. My short-term plan is to keep everything private and therefore I don’t want to be forced to cram multiple projects into a single repo for short-term budget reasons.
Next up is AWS CodeCommit, which was recommended to me by Michael Lee in a recent conversation. He wrote about the reasons for his recommendation in a recent blog post. The key point is that AWS offers a pricing structure based on the number of users rather than the number of repositories. Their free tier allows for up to five users, no individual file check-ins larger than 2GB, and a limit of 50GB of storage per month.
Atlassian BitBucket is similar to AWS in how its pricing is based on the number of users, however they just announced upcoming pricing changes that include limiting their free tier to 1 GB of storage per month.
The Decision
I decided on CodeCommit because it’s hosted on Amazon Web Services and its free tier has limitations that I can easily live with relative to the cost. I’m also confident that AWS can scale with my needs as I make progress toward my goal and have more projects to manage.
By the way, I will keep the free GitHub account because it has the advantage of being a very popular service and it could be useful platform for sharing open source project in the future.
Next Steps
My next post will be about my experience setting up my AWS account and the initial repo configuration.