I've spent much of my recent database development career using different SCM (Source Code Management) tools such as CVS, Subversion (SVN), Perforce and GIT. I used them even if there wasn't any widespread support or integration of SCM methods among my peers because it would be sheer insanity if I didn't. Once you start using any of them, you'll probably agree... while life without an SCM is still possible, the timesavings, boost in productivity and reduction of risk due to mistakes all point to a real win for the professional who chooses to use SCM methods and tools. For example (explanation borrowed from gitref.org):
Why Would I Use SCM?
If I didn't use an SCM tool, I would most likely start out by copying my current source code file with some distinguishing naming criteria so that I would have at least one good copy (one for archiving) and one for my current changes:
cp somesource somesource.bak
Then maybe as a project progresses, I may have multiple copies with some other naming methodology to allow uniqueness between each "version" of my file:
somesource-01132013
somesource-v1
somesource-project1
etc...
I could post these files to some shared resource so other developers could review or see my versions. But what if one of these files were mistakenly used by another developer as the base version then applied to the database? How would a team communicate between each other that an object was being worked on by another? An even bigger question is: how does a team of developers package up their work and manage changes between different tiers (development, test, production, etc) and still keep things organized?
The primary answer to these issues is to invest some time into thinking through a source code management (SCM) solution, which may include conventions for version control, build and release management. It is imperative to keep track of the software your write, how it changes over time, who changes it and for what purpose it is changed for. Change... (as the mantra goes) is inevitable. It is important to start picking up tools for SCM and the skills to apply it properly.
Examples of Things SCM Solves
Some typical problems that developers can solve and answer with SCM includes:
- How do you keep a history of changes?
- If I don't like a change, how do I roll back to the last known, working state?
- How do I keep from clobbering someone else changes in progress?
- How do I keep track of my own changes privately before publishing the final product for use?
Comment Madness
The first of the questions: How do I keep a history of changes? Many developers may attest that "temporary" or unsure changes are usually "commented out" of code. The code continues to exist, but marked so that the database compiler ignores the excution of the instructions just commented out. This leads to code bloat (inclusion of unnecessary or unused lines of code) and additional confusion as other developers struggle to sort through which is the functional code and which is just commented out. SCM tools keep track of snapshots of versions of code in various states so there is no loss of code. Unused portions can be confidently deleted out with the knowledge that the deleted code can be recovered at any time simply by searching through past versions. This can be said of the need to "roll back" or recover older working versions when new changes fail to pass the test process.
Organizing Changes
Sometimes changes are made in parallel between multiple developers. Simple features like "check out" or "check in" in SCM tools allows changes to be organized between these programmers. SCM tools handles this concept differently so it may help to do a little research first. For example, some tools such as Perforce allows a developer to "lock" a file upon checkout so that others cannot make changes to the file in the master repository until the one who has checked it out has submitted their edits.
Sandboxing Projects in Progress
Some SCM tools require synchronization of source code files between a master repository (remote) and what is kept locally on one's machine. Git, for example allows the cloning of a remote repository to a private sandbox (local machine) where edits and adds can be made. Git allows an unlimited amount of submit actions to the local repository. Then, when the developer is ready to push their final changes to the remote, shared repository, all their tiny edits are represented as one single change... the final product since the last time they copied from the remote repository... preventing the remote repository from being littered with the atomic edits made during the development process.
Getting Started with SCM
There is a free tutorial video and interactive demo available at Code School (
http://codeschool.com) called "Try Git" which even gives you an opportunity to set up a free account with github, a popular cloud-based Git hosting service. Other places where SCM tools are actively used and available includes: Source Forge, Google Code, and others. Give it a try and see what it can do for your productivity as a single developer or as a member of a team of programmers together!
No comments:
Post a Comment