Saturday, July 6, 2013

Quality Control

In a few of my posts I've mentioned the concept of quality control, and so in this post I'll flesh out that concept a little further. Let's say a company has a pretty sizeable website and they want to make 10 small updates to it, as well as completely re-do the entire design. To complete these tasks they have five developers. One of those developers works on the re-design for five months, and the other four developers complete the small updates as they come in. Now lets imagine that this website is being used day in and day out. This means that we don't want the website to stop working. Because we don't want the website to go down, we never work directly with the code that is displaying the site to clients. If we did, whenever we created an error pages would fail to load, and functions would fail to work. For that reason, quality control methods are used. Let's say we take one developer who is making one change to the website. Because that developer doesn't want to update the website itself, he or she makes a copy of the website. We will call the production website a "master" branch. So we have one core branch that exists in a production environment (what clients see). To make a change a developer "branches off" master and takes their own copy of the website. They then make the changes, test them, make sure their copy of the website is working properly, and then push their changes back into the master branch. But wait! There are three other developers working on the same site, with their own copies, on their own branches. What if some of their changes to the website don't exist in our developer's branch? This is what's called a "merge conflict". If developer A updates his branch, and pushes his changes back into master, and developer B has created a branch and needs to push his code into master, but will over-write developer A's code, github, a quality control system, will refuse the change until the merge conflict is resolved. This means that the developer who is trying to push into master will have to ensure that any code that would have been over-written exists in their branch. The developer who is spending five months completely re-designing the site has taken a copy of the website into their own project environment, and then makes further branches off of the core branch that they have branched from master To give a visual the process looks something like this: Using this mechanism, we allow a handful of developers to do work on the same code, and ensure that that all of their changes can be pushed to production in sync. - Full Post

No comments:

Post a Comment