blog

Getting started with a modern source control system and DevOps

Published on
9 minute read

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, they are about the metadata that you use to understand and manage your development processes and deliver great software. The tools you choose should compliment the professional people and practices that you use.

DevOps is the union of people, processes, and practices to enable continious delivery of value to your end users

Donovan Brown

TL;DR

I have been teaching the Professional Scrum Developer (PSD) training  and working with software teams for 7 years. I have never encountered a better platform than Visual Studio Team Services (VSTS)  for managing the metadata required to facilitate the building of professional software on a regular cadence in any technology that is deployed to any platform. I have seen Java, .NET, Web, Android, iOS, and Mainframe teams all working together in VSTS with a shared vision and access to the same metadata. If you have many teams I did a webcast for Scrum.org on Scaling Professional Scrum with VSTS. 

Let’s 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. Would you want your real-time transactional banking system under source control? Coz I would!

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. One customer required to do 9000+ hours of manual testing to validate that

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 past, you used VSS, Subversion, or Perforce and it was good enough. Not anymore. 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 and for them all to be integrated. 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.

I would expect my release tools to understand exactly; what changes have been made to the code, which features of the system are affected, and what the resulting impact of that release had on both the user experience and system performance through telemetry. I would expect my work tracking tools to understand exactly; what branches are related to this work, which build include the changes, and who approved the pull requests that brought that code into the system. This is the type of metadata, regardless of the implementation technology, that I would expect to be available to Engineering and Management to help them understand their process and how things are going.

That all said it is important to remember to focus on becoming a professional Scrum team  rather than an amateur one. While you need to focus on the Scrum Guide, you also need Engineering Excellence and a set of Values and Principles.

I almost never use the term “best practices”, especially for software delivery and anyone that gives you a best practice is generally talking out their ass. There are only good practices that fit the current needs of the business or the situation at hand. 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 need to be able to monitor both your Lead Time and your Cycle Time.

Some general guidelines you should consider:

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 us 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. Regardless of your implementation choice, VSTS can support your teams doing Scrum and deploying anything on a regular cadence to anywhere. When I am teaching a Professional Scrum Developer (PSD)  class I always use VSTS regardless of the technology that the students are working on.

Don’t get locked into a limited set of technologies, VSTS supports every technology on every platform.

Find out more on Visual Studio Team Services  from naked Agility - Martin Hinshelwood  .

measure-and-learn blog developers devops engineering-excellence homepage software-engineering versioncontrol

Connect with Martin Hinshelwood

If you've made it this far, it's worth connecting with our principal consultant and coach, Martin Hinshelwood, for a 30-minute 'ask me anything' call.

Our Happy Clients​

We partner with businesses across diverse industries, including finance, insurance, healthcare, pharmaceuticals, technology, engineering, transportation, hospitality, entertainment, legal, government, and military sectors.​

Genus Breeding Ltd Logo
Freadom Logo
Alignment Healthcare Logo
Bistech Logo
Boxit Document Solutions Logo
Higher Education Statistics Agency Logo
Xceptor - Process and Data Automation Logo
Lean SA Logo
Flowmaster (a Mentor Graphics Company) Logo
Slaughter and May Logo
Emerson Process Management Logo
Big Data for Humans Logo
Teleplan Logo
Sage Logo
Deliotte Logo
Schlumberger Logo
YearUp.org Logo
ProgramUtvikling Logo
Washington Department of Enterprise Services Logo
Nottingham County Council Logo
New Hampshire Supreme Court Logo
Ghana Police Service Logo
Royal Air Force Logo
Department of Work and Pensions (UK) Logo
Sage Logo
Alignment Healthcare Logo
Microsoft Logo
Slaughter and May Logo
Milliman Logo
Trayport Logo