GIT For Non Developers, Part II

GIT For Non Developers, Part II

150 150 admin

Our experience as a team, after implementing our version control best practices with Git has been an amazing one. After writing a first post on Git for non-developers, we decided on a continuation, to share with our community how using Git has enabled us to deliver higher value for our clients.

If we, as CSW developers, have to mention our most important tool for delivering great quality service everyday, Git would fall into that list.
Of course, Git is just one tool among many available for implementing source code version control, which, as a best practice, is much more important than any other specific tool. Even though version control has been available for decades, we’ve been doing amazing things thanks to Git’s strengths.

By the way, here’s a quick note on what version control is (from the Git team itself), but we’ll get into it briefly too:

Best practices with appropriate tools add value.

In simple terms, version control systems are tools to help developers keep track of changes done when source coding during development of new features, and during the implementation of bug fixes. Such changes may happen in a serialized way, i.e., every new change is just added to the latest version available, but quite often those changes happen at different time tracks, and are performed by different developers working on the same project, which makes controlling all of those versions not a simple task.

Git helps programmers (and teams of programmers) keep track of different versions of code, an important task when multiple team members might be editing the same piece of software. It can compare two different code snippets and tell you what the differences between them are, and who made those changes. It can also tell you how all the changes in a project compare to each other.

What our clients want is to get their software project progressing as fast as possible, while keeping product quality at an optimum level. Such a goal requires tools and best practices enabling us to do so, instead of becoming obstacles on our way.

When version control is done right, you can keep changes done for the production version separate for a future development version, and required bug fixes while performing QA on the almost ready to-be-released version.

In the past, version control tools would usually allow having only one trunk, and the recommendation was to have only short-living branches that should be merged back as soon as possible.

git i

With Git (and in general, with distributed version control systems), that limitation is not there anymore. Developers may continue doing things the old way with Git (and we’re sure a lot of them still do), but we make use of the advantages Git has provided.
We are now safe to create as many branches as we want, to have those branches spanning over long periods of time, to easily merge and rebase our branches whenever we want and, to easily jump or switch from any given application version at any time.

A regular Git repository for our client projects here at CSW Solutions looks like this:

git 2

We always keep a long living branch (source code version) that holds exactly what’s implemented in the production system/live site. We can always check out the latest stable version that was delivered to the client, and that’s an amazing value to provide. We also keep one track with the latest development version (usually known as trunk – here called “develop”).

Our current branching strategy follows this amazing idea proposed by Vincent Driessen.

OK, but as a client, what’s in it for me?

We’re glad you asked! 😉 Normally, all of this detailed explanation is something that remains in the kitchen of software development shops, but it pops up more often than not when parallelism takes place on the tasks of a given software project.

Let’s make use of an example:

Suppose you have a website which is constantly improved with minor fixes, and at the same time, you’re expecting to get a more complex feature from a separate track. Minor fixes will be completed much faster than complex features, even if they are requested after that track was done. In any case, no piece from a complex feature may be implemented in the website until it’s complete, as that could become a breaking point in the stability of your website. There’s no way that can be achieved if version control occurs in a serialized fashion, without parallel feature branches.

In a much more complicated situation, some critical bug may be found in a live site, and the latest development version is not yet ready to be deployed, which is the version your project’s development team is currently working on. They need to be able to stop their work, jump into a copy of what has been implemented in the website, and get that version’s hot fix completed. You, as the client, just want the fix to get done ASAP, as your own customers are suffering due to the critical bug, and so is your business.

As simple as this may sound, it may be cumbersome to get this done with the old tools, as we’ve been in these hard situations in the past. However, with Git and proper implementation of best practices, this has become a simple routine task done on a daily basis, and it has worked for us.
For our clients, situations like these are solved with no hassle or delay, and value is effectively added to the services they are receiving.

Git provides us with the ability to jump into the appropriate context and meet your requirements quickly, no matter at what point in the development cycle we are in with the upcoming development version.

A window for the client to watch code evolution.

Thanks to Git and web services like GitHub and Bitbucket, it is now common to be able to browse source code and easily traverse over different versions, branches and commits. It’s easy to track through web interfaces to find when and who made a change, and in which branch. This has been wildly used for open source and public code to be shared among different developers, but all of those benefits are also available for private repositories. It’s in private repositories, and under services like these, where we maintain and control all of our client’s code versions.

This has also allowed us to provide extra value by setting up the repositories in a way that gives our clients full access to the latest version of their project’s code. A lot of clients may not be interested in reading their own website code, even if they have access to it, but, if not provided, that can be easily interpreted as lack of transparency: it’s our client’s project, and it is that project’s source code, and all of our project progress has to be reflected in code changes, which are available for our clients to see. If they feel they need to do some auditing on our code, it’s fully available for them to do it, and if they want to run a blame command on a breaking change… well, they can do it too.

At CSW Solutions, we are proud of the quality code we deliver, and having it available to our clients at any given time is part of our practice.

So, let us know: would you like to know more about having these benefits on your next software development project? Give us a call, send us an e-mail, let’s chat!