Every software developer should be familiar with some type of versioning system, be it git, Subversion, Mercurial or some other. The advantages offered by using such a system are plentiful, they are that vast that such a system is often also used for other types of documents, be it in a different format. Services such as Google Docs, OneDrive or Dropbox offer the exact same features because they have recognised that having a history of your documents goes way beyond source files.
So we all acknowledge that keeping your data in a versioning system is a good way, but this opens up a different question. How should you organise your documents? I don’t mean which folder hierarchy, which in itself is already a challenge, but I mean the actual location. It makes sense that you want to keep your files close together, but how do you categorise your documents? Based on topic, type, target audience?
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.
Depending on what type of business you are active in, you either often start new projects from scratch, or not at all. In the first case you are more involved with proto-typing and experimental work whereas in the latter you are working on a product that needs to be supported, upgraded and maintained.
Starting code from scratch has a lot of benifits mostly caused by the freedom that comes with it. You are not bound to any choices made in the past, you are free to choose your own way of working that you are used to and feel comfortable with. There is also no legacy code that you need to understand and may be badly documented.
But what I want to address in this blog post is all the side-setup that is required when setting up a new project, and how important it is. Should it all be done from the start? Or can you delay it until it really becomes important?
Every company nowadays needs some software to operate, ranging from a public website to an internal shared drive to some 3rd party software for managing finances and customers. Typically this software would run at a server inside of the company but with the rise of cloud software more and more companies allow you to run their software on their servers instead of having to run it yourself.
This is nothing new as most often companies already out-sourced the management of the website to a hosting company that takes care of security, maintenance and availability. Now it is possible to do this for other software as well, but should you? In this blog post I will discuss the advantages, disadvantages and some remarks that must be taken into account when thinking about switching to the cloud.