There are a number of things that you have to think about when selecting a modern source control system. Some of that is purely about code, but modern source control systems are about way more than code. They are about your entire application lifecycle and supporting DevOps practices.
Lets get some things out the way first
If you are writing code then it SHOULD be in Source Control. More specifically, if you are writing code for your company then it MUST be in Source Control. Every line of code that you write or change is an asset of your organisation and should be reflected on a balance sheet somewhere. Any value you add is capital expenditure, of which your shareholders/owners should care, and any maintenance is operational expenditure, which your accountants can write off.
Put your code in source control… and yes, I still meet organisations that DON’T use source control. No, not only small sweatshops, but banks as well.
Another thing to get out of the way is that deploying directly to production is a BAD IDEA! If you are deploying from your local workstation then you are introducing significant risk to your business and reducing the quality of the organisational asset. Any reduction of quality is a decision that needs to be taken by your executive board on advice from your accountant. Again, organisational asses sitting on a balance sheet. Its fraud to incorrectly represent the value of an asset, ignorance is not an excuse. Even if you have automated builds, if you ship irregularly, or with a lot of time between releases, then you likely have a way to bug-fix production quickly. Bypassing your usual checks and balances for shipping software reduces quality and shows an inherent lack of engineering excellence in your organisation.
Deploy software through an automated release pipeline… and yes, I have met companies that deploy directly to production from workstations. I even worked with one company that had operations using trial and error mixing and matching DLL’s to get the software working in production.
Modern source control is more than just code… in the past, just like operating systems used to be simple things, you could stick your code in source control and call it good. In the last you used VSS, Subversion, or Perforce and it was good enough. Not any more. Just as you expect a browser to ship with your OS, you now expect a Build engine, release management, and planning tools to ship with your source control system. So don’t base your choice on that one thing, think of the integration and other tools that you need to support your modern software development pipeline.
Recommended good practices for a modern software team
I almost never use the term “best practices” especially for software delivery. Anyone that gives you a best practice is talking out their ass. There are only good practices that fit the current need of the business. In the modern software development world you need to accept that any process or practice that you adopt is imperfectly defined and will need to be adapted to meet your needs. That said, having source control and an automated release pipeline is not optional if you want to continue to be competitive. You may also find this useful:
- Never code without Source Control – Ultimately the tool does not matter but if you are building Open Source Software (OSS) then you need to be on GitHub. GitHub has cornered the OSS market and has not near competitor. If however you are building closed source software then there is no better platform than TFS/VSTS which gives you unlimited private repositories. If you have MSDN licences, as most organisations building on the Microsoft stack do, then it is already included in your licence.
- Use feature flags to minimise branches – Branches introduce waste with merging and often introduce quality issues. Bypass the whole issue by using Feature flags and other software patterns to avoid it. If you are using a distributed source control system (DVCS) only ever release from MASTER with fully tested code, but you can have unlimited topic and personal branches. If you are using a server based source control system (SVCS) then you should completely avoid branches where possible. Maybe you need only [trunk/master/main] and [dev/work] branches but focus on a zero branch policy.
- Meet your Definition of Done at least every 30 days – Create a definition of done that represents the minimum bar of quality for everything your develop. Make sure that definition reflects everything that you need to do to ship your software to production, and get there at least every 30 days.
- Get feedback from your users at least every 30 days – Part of the trick of delivering awesome software is building just what your customers need, just as they need it. The only way to do this is to get what you have just built into your customers hands so they can tell you is it is right, then pivot as soon as they give you feedback.
- Create tests first so you build what was asked the first time – You should always work towards test first practices. While for many this means Test Driven Development (TDD) I like to look it as any form of test first. How can your coders ever hope to pass the quality gates when the testers build the test cases separately and only show the coders after they are finished. Get your test cases written first and have the coders make them pass. I also recommend that coders use TDD and pair programming. Following Test First will help you move from testing quality in at the end to building quality in from the start.
- Automate every test you can – Automation is key to a successful delivery because you can’t run all your tests every 30 days. Every 30 days you add more tests and without automation you can’t keep up.
- Create automated release pipeline – Creating an automated release pipeline is hard but the benefits are numerable. From quality to resilience you just must have one to support modern development practices. You should focus on delivering to production (start with as close as you can get) at least every 30 days, but expect to need to ship many times a day. Automation will make your process quick and easy an lets you focus on improving the pipeline over time as you his issues. This is where lean practices and focusing on flow can really help minimise the waste and improve the process.
In order to support these things I use VSTS as my software development platform. With the move by Microsoft to distance its platform from execution and focus on orchestration we get a system that can support any team developing with any technology for any platform. This allows use to have a single unified organisational vision and tool for our orchestration of portfolio, planning, execution, coding, build, test management, and release while leaving the execution of these tasks and the technologies used in and to build our software up to the team. You might have one team that used Nuget and another than uses NPM, or one using Maven and another on Gulp.
Don’t get locked into a limited set of technologies, VSTS supports every technology on every platform.