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.

What problems does scaling brings?

Moving from one to several developers might bring several difficulties like:

• Having several developers working on the same file
• Managing a framework upgrade while another developer is coding new features
• Correcting bugs while we are currently developing new features
• More developers bring more bugs

Let’s start from one tool: The Repository

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.

Let dive into some details about repository management

There are several concepts to understand to take all the advantage from a repository:

• The Branches: A Branch is a dedicated version of the repository that has been created from a copy of another branch. For best results, allow only one developer to work on one branch.
• Master/Trunk: The Master or the Trunk is the main branch of the project. Development and deployment often starts from it.
• A Fork: A Fork is the action to copy a specific version of the software, usually but not exclusively from the master. This concept exists from developing a very small little change that is going to be integrated into the main project. A good example is Linux Redhat fork : https://en.wikipedia.org/wiki/Red_Hat_Enterprise_Linux_derivatives
• A Tag: A Tag is like a Branch, but it freezes the software project with at a specific feature update. A Tag is mainly used for bug fix.
• A BigFix is a small correction that should be applied to a branch. The best practice is to create a dedicated branch for each bug fix and then merge it once it’s finished.
• A Commit: when a developer is pushing his work on the repository. Could be on the master any other branch.

One feature = One branch

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.

Tag/Version Management

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.

Global overview

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

Conclusion

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.

The post How software developers should manage their development process appeared first on Out Of Tech.