Before starting any actual development I decided to dive into the features GitHub provides. Since it is just a personal project, I see little reason to start hosting my own Jira or other heavy applications that I would need to keep running somewhere. Instead I would opt for free cloud-based solutions. As a fact I know that GitHub has a lot of features, which is nice because then everything is located in a single location.
I have however never used any of these features, and thus I was out for an interesting journey on setting everything up. In the end the goal was to have a nicely organised repository with a clear flow, where merging branches and continous integration is standard.
The first step would be to start using the features of GitHub, most of them represent known things to me, such as issues, milestones, wiki, … Using issues and milestones is just a matter of using them. So I created a single milestone and all issues that need to be done to achieve it. The Wiki is a different story, as I feel like this is something you only need later on, therefor I delayed investigating this.
GitHub also has a concept of ‘projects’ which turns out to be a simple SCRUM/Kanban board. Since I do have good experiences with this in the past, I started using it as well. I do however wonder whether it will be very effective since I am the only developer, and I only created a single project to cover everything. I don’t know why you would create multiple projects, perhaps seperated UI, backend, and parts of the application? You wouldn’t want to use a board per feature, because that’s what the milestones are for.
Besides just setting up the repository and the project itself, the build process needs to be setup as well. This however causes a ‘chicken or the egg’ problem. You can try to setup a build setup, but you can’t really test it until you have code. But writing code first and then setting up the build process means that your initial code will be merged without being able to be build. It makes sense to co-build these two things, but since I use branches for the issues and I don’t want to use issues for non-code work this does cause a problem. I would end up mixing code development with process setup within the same branch. Instead I have decided to artificially create the build process after writing some code, but split it and merge it to the master branch first before the actual code.
This way it looks like everything was taken care of before any code was written, even though this was not really the case. A similar problem occurs with libraries (such as fakit and gtest). This however, I feel is more justified to be added on an is-needed basis. So mixing this with the actual code feels like a normal thing to do, as you clearly see why they were added in the first place.
A similar story is the actual continuous integration build. Instead of setting up a local Jenkins, I decided to go for Travis, which is used by many open-source projects. This however requires a .travis.yml file, which again raises the question on when to add this file, such that the code can get build. I repeated the same trick as with the build process such that I was able to test the whole setup with real code, but in the end make it look like this was already taken care of before any of the code.
I would still like to setup a bit more processes such as code coverage, code analysis and style checks, but for now this will do. I ended up with a properly setup GitHub that is able to track evertything, a build process consiting of CMake, and a Travis that automatically builds all pull requests.