I want to use this project log to explain a bit more about the infrastructure behind the Kitnic site and how it is deployed and hosted.

Kitnic.it is a proof of concept site. I want to prove that there is a need for it, that it will foster collaboration and that people will use it. For this I wanted to build the minimum viable site. I wanted to not spend very much on hosting it and I wanted it to be low maintenance in case it gets to the point of being useful but not worth investing a whole lot of time in to.

When sketching out the minimum functionality of the site I realized that I could leverage existing services to host the site, deploy improvements and even allow people to add their projects without investing any money into hosting infrastructure.

The site is built statically which means there is no server-side process reacting to user requests. A static site can be hosted on GitHub for free using what they call GitHub Pages. To make use of this you create a branch on your GitHub repo called "gh-pages" and push any static files you would like hosted to it. GitHub has much more in-depth instructions on how to do this.

Making the build make sense

Our site is build using Javascript and React. I tried a whole range of Javascript build systems and task runners to try and build the site but coming from the embedded systems of C, C++ and Makefiles none of them seemed to make a whole lot of sense to me. They all seemed to miss the essence of Make, where you describe inputs and outputs in terms of the file-system and it takes care of tracking dependencies and hence only re-builds things that need to be re-built.

On the other hand my Makefiles do tend to get a bit out of hand and the syntax isn't the nicest. I also didn't want to scare of potential Javascript hipster contributers by saying "Hey we use this build system from the 80s to build the site".

I settled on a modern re-thinking of Make that, in my opinion gets it right : Ninja. Ninja focuses on the bare minimum of make-like syntax and is intended to be generated from a script. We use Coffeescript as a scripting language and the npm library ninja-build-gen to generate a build.ninja which is then parsed by Ninja to run all our build tasks. This does an excellent job of tracking what needs to be re-built when you change a file.

The registry

Users can register their project with Kitnic by simply appending their git URL to our boards.txt file. This way we can leverage GitHub's collaboration tools to do manage contributions. When the file is edited GitHub creates a fork of the project and the user can then send a pull-request to our repository where we have an opportunity to discuss any issues with it and make sure they are happy with the resulting page.

We use a free service called Travis CI to automatically build anything that is pushed to our GitHub repo:

1. Changes pushed to the master branch are deployed to kitnic.it if the build succeeds
2. Other branches are deployed to *.preview.kitnic.it, so for instance the "issue-31" branch is previewed at http://issue-31.preview.kitnic.it/
3. Pull-requests are built but not deployed right away. Travis does not allow this as secret deployment login information could be leaked by anyone making a pull-request. If the build succeeds and there are no issues with it a Kitnic member creates a branch for it so it can be previewed.

The build scripts will automatically get the latest version of the git repository and put it into the registry.json file. This file is used to checkout a specific version of a project and that is used that to make the page.

We will periodically update the registry with the latest versions and make sure the build is still successful (and fall back to the last version if not). In the future we would like to be able to provide multiple versions of the same project and allow for tagging a release, so you can tell people this is v1.0 of the project and this is v2.0 and let them download the files for each.