Growing startups often need to expand from one single developer to their first development team. What work for a single developer might not work for the entire team and they no longer can work in the same way. Each developer has his own habits, depending on their previous experience. If they worked in a large team or if they’ve previously worked as freelancer, they might have their own approach to manage the development process. There isn’t only one best solution that fits all scenarios. But here is the organisational structure that I often propose to a growing startup.
Moving from one to several developers might bring several difficulties like:
When we are looking for a correct way to manage development, the first thing we should think of is the source repository. Today, it’s usually a Git repository among bitbucket, bighub, beanstalk or even a self made repository based on GIT, svn or maybe still the old cvs.
A repository is a kind of file sharing platform where developers can share all their work in one place. Not only it allows saving files in a safe place, it also does save all files changes since their creation. Another very useful feature called branches, which allows developers to create their own repository version to work on whatever they need, and once they finish their work, they can integrate/merge their work with other developers work.
There are several concepts to understand to take all the advantage from a repository:
At the beginning, branches were not used as massive tools, but unit tests and continuous integration, led developer teams to create one branch every time they do a session of development.
The principle is quite simple, before we integrate a new feature or bug fix into a root branch, we run a maximum amount of tests and then we integrate it only if everything is ok. This practice is very useful and could be linked to a Bug Tracker or Issue Management tool like: Jira, Mantis, Bugzilla, Taiga and lots of repositories have their own solutions like Github, Bitbucket, Beanstalk. This link is usually done by a very simple trick, we put a #15 in the commit message and then the bug tracker software takes all the information regarding the issue no 15 and links to it.
1 – Patch management: 2.0.z
When you come to a stable version of your software, you should create a tag with a dedicated software version. Let’s take as example version 2.0. This version shouldn’t evolve or have any need features. Any new version, like 2.0.Z for example, would only be a patch version with bug fixes or maybe very minor design change. As usual, every time we start developing a bug fix, let’s assume the version 2.0.1, we should create a new branch version and integrate it after all tests. In that way a bug fix should be able to be deployed in production within few hours without compromised the entire software stability by pushing untested features.
2 – Managing improvements and new features : 2.Y
As soon as we talk about adding new features, we should create a version 2.Y where Y is the new increment version.
Every time we create a new version we should create the tag version where it’s ready for deployment.
3 – Managing major version.
A major software version like version 2, version 3, should occur only when there is a major update with many new features, or with a new framework version. It should only happen about once a year or event less.
I’ve tried to put in a nutshell what we shared above:
1. You have a master branch.
2. Every time you accomplish a development you wanted to deploy into production, you should create a tag branch.
3. This tag will only evolve for bug fix, nothing more
4. When you develop a bug fix, you should create a branch specially for it, correct the tag branch and the master branch in the same time
5. On every new development you should create a new branch and integrate it into the master once it’s corrected
Here is what I recommend to do regarding the version and repository management. As usual, there isn’t only one correct way to do it, and I would love to ear from you and please let me know how you deal with it.
Look forward to read a comment from you.