DevOps Dissection – Source Sanctuary


Welcome back to the dissection lab! This week let us travel into the realm of Source, taste the fruits of repository branching and have a cup of wisdom. If you’re ever developing software you must use some sort of version control system, otherwise known as source code management.

Source Code Management

 SCM is a means of allowing easy collaboration on a project, a whole group of developers can work together towards a common goal. Version-ing protects changes to the source code facilitating easy reverts and guards against hard drive failure. There are two varieties of SCM, client-server and distributed.

The client-server model uses a server as a single repository for source code. A developer would synchronise to that single repository in order to make changes, very simple pulling, pushing. The distributed model has a central server but every developer has a local copy of that repository on their HDD. An example of each are Subversion and Git, each with certain advantages and disadvantages.


 SVN follows the client-server model. It is very easy to learn as at a basic level all you need to do is checkout the repository, make a change and commit it. A team of developers can pick it up very quickly with just 3 commands and anything more advanced (branching) can be incorporated on the fly. Unfortunately due to the centralised nature of SVN it requires network access. So if you’re on the move and don’t have internet access you cannot make any changes.  On the plus though newbies can pick up SVN with a really good GUI, TortoiseSVN.


 Git is the absolute boss when it comes to SCM. The commands are a little more in-depth and there are more of them than SVN, with quite unfriendly error messages, but it allows development anywhere. If you had a server at home and a laptop on the road you would be able to continue working as you’d have a local copy of the repository; when you regain network access you can push your local changes to the server for the entire team. Additionally every development machine becomes a local backup of the repository, protecting against server failure. In general Git is faster than SVN anyway, it was built for the Linux kernel and can easily scale up to hundreds of developers, although as you’re checking out the entire repository you could be waiting on a long download. It’s a little unfriendly and the GUI is awful, to use Git you’ve just got to make the command line plunge (cmd is just better anyway).

 Branching and Merging Strategy

 No matter what SCM tool you go for it is best to follow some standard practices and properly manage the repository. Disasters can occur when developers are working on the same files concurrently, to counter this branching can be utilised. Branches are copies of the repository, within the repository, effectively a duplicate which allows work to be separated out. The generic idea is to preserve a master branch on the repository, this branch has passed integration tests and can be passed on to release. All development happens separate from this branch and can possibly occur across many branches depending on the nature of coding.

For instance, take a master branch at version at 1.0.0, a new feature for the product will have a feature branch created and designated as 1.1.0, while a hotfix to the master may be designated 1.0.1. During development once a branch has been completed and tested it is merged into the master, rebranding the master as that version. If the above hotfix is incorporated before the feature were completed then the new master would be merged into the feature to keep it up to date. An illustration is perhaps the best way to go:


This is quite rudimentary and it can get more complicated if you have even more future feature branches, but as a starting platform it’s quite nice. Ideally for long term development the features and hotfixes should be periodically merged into the master anyway (at the end of sprints), this defeats conflicts early. So now this removes some of the pain with parallel development and enables easy tracking of new features and hotfixes.

Thanks for reading, tune in next time for a breakdown of Issue Tracking with JIRA!


Microservices in the workplace


Hi, my name is Gareth Andrews and I am a Consultant at QA Consulting. I am currently deployed on client site as a developer, and an occasional Scrum Master when my services are required. Alongside this I am also training for a qualification in Information Security Management Principles. My current role as a developer has an emphasis on the production of Microservices, which brings me to the topic of this blog.

So what are these Microservices and why are companies, who can be gigantic entities with hundreds of employees working on software, looking to include them into their systems?

“Microservices” is a term a lot of companies use, but the description that is widely accepted is ‘where complex applications are comprised of multiple independent processes’.

The typical fall-down for many companies is that they keep expanding their systems, offering more and more without considering just what would happen if someone fell down. Imagine a large tower with many floors, what would happen if you suddenly decided that you wanted to move the bedroom from the 1st floor to the 5th? With Microservices, your architecture allows you to move, replace and update as you go along, with support available for both new and old features enabling you to create a stable and adaptable framework.

Companies like Netflix and Amazon use Microservices in order to help scale up their products, with new features and applications simply requiring you to add rather than adjust.

The point of Microservices is to be able to communicate between one another, with this varying depending on how you want the systems to work. What better way to communicate though than with HTTP web calls, the same way you would go about loading up Youtube or Facebook after a long day at work?

RESTful web services are written with the internet at heart. These services allow you to navigate to an address and get responses – much like you would when you search for that ticket website in a rush. Allowing access to Microservices through calls to addresses means that all of the Microservices are accessible to one another, with none having to actually know about any changes except their web address.

I think this quote by Richard Branson is a great place for me to finish “Complexity is your enemy. Any fool can make something complicated. It is hard to make something simple”.

Life on Site with Gareth Andrews


One of the advantages of being a consultant is that the future is open to you. I am currently working towards getting a certification in Information Security Management, a certification that would better equip me to deal with the everyday risks and issues of security in a digital world.

Training and expanding on your skills is a must these days, where jobs and opportunities are difficult to come by. There are many training courses available and talks held to help you learn and understand everything from techniques to new technologies, there is not a single week where I feel like I’ve not developed in some way.

With every moment being a chance to develop, it’s hard to not see something great coming your way.

So that’s me, past, present and future. I hope that these blogs have been useful in understanding just what we do as consultants for QA Consulting, from the fast paced rush of fixing issues to the calm and collected analysis required to plan ahead for the next piece of work weeks before you even start creating the code.

QA Consulting has given me the opportunity to put my foot in the door for a very competitive market with all the support I need to work for a high end business straight out of the Academy. Going forward I hope to train and develop my skills in information security so that our clients can rest easy knowing that with my  skills and expertise I can help to protect their data.


Life at the Academy with Gareth Andrews – The Hackathon


The QA Academy opened us up to many opportunities and experiences, the Hackathon was by far the most memorable. Starting in the afternoon on a Friday, teams gathered and started discussing their mobile app ideas with the intention to create the apps in 24 hours.

A few minutes in and a man-sized gorilla could be found roaming around the office spying up our ideas and getting a few laughs in the process.  A few hours later and the party is joined by a gangster, princess and Mario, all in time for the pizza and snack foods that went almost as soon as they had appeared.

The hackathon ended the next day, with a countdown ticking away the seconds before people were ready to leave the office, having lost teammates to fatigue and weekend plans alike. As we left the office with sleepy smiles I still remember thinking about how much fun we had, and how we had managed to fit an entire project cycle (staffing issues and all) into 24 hours, all before I hit the pillow and lost the Saturday to sleep.

The QA Hackathon was a great experience and will definitely not be my last,  I can safely say this is the one that will stick with me for a long time.