Just wanna share here the common terms I’ve learned from my experience working as Source Control Administrator for a multi-national company. Why did we need source control? Mainly because we have programmers all over the world and we have to maintain a standard system enterprise-wide. That means we should be maintaining one set of source code that are maintained by programmers from different places.
Why only one set? That’s because the system should be identical wherever they are implemented. So the system we’re using in Dubai should be the same as what they used in Houston, Singapore, Baku, Batam, etc… That’s some of the actual places where our system was in use, just to give a perspective to the diverse location we’re talking about.
So why do we have source control? That’s because if we don’t, the source codes will be all over the place and nobody knows exactly what and where is the latest version. There’s also the danger of fixing one problem and giving back the other. That’s for the scenario that one programmer maintaining own set of code fixes one problem yet another fixing another problem. They will have each their own sets not having each other’s updates; so implementation time, they will overwrite each other’s updates. For example, the original code is “ABC” and user 1 with programmer 1 agreed to make it “ABC-D”. Meantime, user 2 with programmer 2 somewhere else, agreed to another fix into “ABC-E”. With source control, it’ll be easier to come up with global “ABC-DE”. Otherwise, it’ll be tough for users/programmers to keep in touch get updates from each other.
At any rate, here are the common terms:
- Check Out/In
- Dev, QA and Prod
Few more details for each:
Pretty much the main folder in “File Explorer” environment.
In fact with the system we’ve used, and I guess in most others, it is presented that way.
In our setup being a big international setup, we grouped projects into Accounting, HR and Operations.
The rest of the projects are under those main groups.
This brings back good memories, eh?
A playground area on the sand where we play with our toys outdoor.
Similarly, sandboxes are your local copy of the source code.
Each programmer can have their own local source code to play with.
As it is local, it does not affect the shared server copy.
Yet anytime with proper access, local and server copies could be synchronized.
That’s where the next term comes in handy.
As in most usage, checking in means getting it in and out is getting it out.
Check in means you’ll be sending your local copy to the server.
Check out means you’ll be getting copy from server to your local.
When you check out a code, it’ll be locked for you.
Each time you check it in, a bubble point will be created, comment then is useful.
That means no one else can do updates while you’re check out.
It was therefore, recommended that at the end of the day, finish or not, check in your works.
That’s so no one else unnecessarily waits for you.
This would also ensure that everyone will always have the latest copy.
The other terms used for this is push/fetch.
Next terms shows you how to spot codes to check in/out.
This simply means changes or differences.
With our system, you’ll be able to spot this by having a red triangle icon in front of the filename.
This means that your local copy is not the same as the server copy.
You then have the option to synchronize your local copy.
Dev, QA and Prod
These are the system environment we’re working with.
Dev means Development, mostly the local programmers’ copy.
QA is the Quality Assurance, accessible only to administrators not to programmers; is copy of Prod environment.
Prod is short for Production, which is the environment actually utilized by users.
This would be quite a challenge to lone programmer who’s entire environment is their own computer.
Another tough concept for lone programmers.
This just seemed irrelevant.
Bit difficult to explain too.
Suffice it to say that checkpoint preserves the source code at that point.
That means that you can always look back at the source at that point, yet you can go on updating it.
This is handy when you’re working for additional functionality.
The Prod version is always checkpointed.
So naturally, you would want to start from prod version.
From checkpoint then, you can download local copy of the latest prod copy.
As you check out/in to update, a bubble is created everytime above checkpoint.
By the time all is ready for prod release, a new checkpoint will be created again.
In our setup, only the source administrator can do checkpoint and release copy to prod.
That ensures that we have copy of the prod source code.
As the term suggest, there will be more than one way.
Normally, there will only be one path of check out/in, from dev to QA to Prod.
There are rare cases though where two programmers need to work on the same code.
Normally it happens when QA take longer time to finish and another issue needs to be resolved.
In this case, a branch has to be created so it could be deployed without waiting for the other branch.
Each programmer then works on their own branch.
Checkpoint will be made on the branch that will be deployed first
Eventually, branches needs to be merged, i.e., combine again into a single path.
In our setup, we made it the responsibility of the last programmer to ensure that codes are merged properly.
Merging normally happens so the checkpoint will be put back into a single path.
Lately, was glad to came across a free online version, with few more terms:
DVCS – Distributed Version Control System
Issues – For recording, tracking and resolving whatever problem occurred
Wiki – Quick documentation, a built-in function of some DVCS
Enjoy your source code!!!