Read on to find out how you can win software to help you integrate Source Control into your development environment!
Why is it good for developers?
What does the business get?
Win a Red Gate Source Control license!
What is source control?
Source control is a means of keeping every change you make to your code, so that you can at any point see what's changed, or go back to a point in time. This is a relatively new concept to database developers, who are used to dealing with the database as a database, not as a collection of objects and data which can be scripted.
Source control has been in use by application developers for many years – and there are many flavours to choose from; some open-source (e.g. Git, Subversion), some closed source (Accurev, Team Foundation Server). There are many pros and cons to each system, and there’s a good source control comparison here which may help to work out which might suit you best. You may have one elsewhere in the business which can be used. This may help to reduce resistance to adoption – but you need to ensure that the source control system you choose can work for you.
Source control has been in use by application developers for many years – and there are many flavours to choose from; some open-source (e.g. Git, Subversion), some closed source (Accurev, Team Foundation Server). There are many pros and cons to each system, and there’s a good source control comparison here which may help to work out which might suit you best. You may have one elsewhere in the business which can be used. This may help to reduce resistance to adoption – but you need to ensure that the source control system you choose can work for you.
The second linked area to consider is integration with your
development environment. I find that application switching is time consuming
and saps concentration – so I want an easy to use solution which isn’t going to
distract me. Some developers will use SQL Server Management Studio for database
development, others will use Visual Studio. Some even use a text editor like Notepad.
With the exception of the latter category, there are tools that will integrate
with your environment to some degree or another - whatever you use.
A key factor in how you use source control is whether you go
for a shared
development model, or a dedicated model. Whilst there are advantages to
both, I've found that the dedicated model integrates better with source
control, and developer SQL Server editions are really quite cost effective so
the cost of multiple systems is less of a factor than it once was.
It is perhaps worth noting that many developers have very strong feelings about the source control system that they are comfortable with, and the reasons they don't like others. I suggest that before you fully implement a given source control system you think about your workflow, what you are trying to develop, and read the adverse comments about your chosen source control system. You'll no doubt find reasons others don't like it - and you can then get a better feeling as to whether this could prove a problem for your team in the future.
It is perhaps worth noting that many developers have very strong feelings about the source control system that they are comfortable with, and the reasons they don't like others. I suggest that before you fully implement a given source control system you think about your workflow, what you are trying to develop, and read the adverse comments about your chosen source control system. You'll no doubt find reasons others don't like it - and you can then get a better feeling as to whether this could prove a problem for your team in the future.
Why is it good for developers?
Source control gives you version control of your changes including history for all changes –
and a dedicated development model will allow you to do your work without
affecting others – yet also work collaboratively should you wish to. The use
of database continuous integration requires source control – or at least a
predictable build script. I’m lazy – and so I prefer to get the easiest option,
in this case source control. Continuous Integration is a key component of
certain development methodologies such as Agile (Scrum, etc.) so if your company is looking at implementing these then you may need to consider it.
One area where Database scripting tools have previously
lacked polish is upgrade scripts – how to make DDL changes without losing data,
or having to script each upgrade. This saves time and allows a repeatable
upgrade – which is great for ensuring your production systems can be
predictably upgraded, and even lead on to continuous deployment. Source control allows upgrade ("migration") scripts to be used to convert between specific, known versions of the software. Most tools will "guess" and some allow you to override specific changes and save the override.
Features such as branches or streams
allow you to develop new code separately to patches to existing systems, and
have a way to get to the database code at any point in time. By having your
application in the same source control as your database, you give yourself the
key ability to get your application and database from any given point, in a
cohesive way so that you know it should build – which is great for reproducing
the system in a known state, for bug fixes etc. You can use the power of your source
control system to get change history, and follow changes to help resolve
issues.
Really key however in my opinion is getting the solution integrated into the development environment. This really reduces the overhead of having source control, and thus you get benefits more quickly. This can often be the first area to suffer when costs are cut, and reduces the immediate productivity benefit of the solution.
Really key however in my opinion is getting the solution integrated into the development environment. This really reduces the overhead of having source control, and thus you get benefits more quickly. This can often be the first area to suffer when costs are cut, and reduces the immediate productivity benefit of the solution.
What does the business get?
For any change to development methodologies to become
adopted by an organisation, it needs to be bringing something to the business –
not just making Developers’ lives easier. So what does Source Control give the
business?
A good source control implementation will mean that
developers are developing against the same code base – less need for concern
about a forgotten table, so the resultant installation will be repeatable.
This means it scales well for new employees, and existing employees are usually
given a list of changed files/objects – so you’re less susceptible to human error in
forgetting to check in a change.
The business may want to support a number of different
versions of the product – for example customer specific installations, or
support of previous releases for a period of time. By having the application
and database code in the same source control repository you know you are always looking at a
consistent version of all layers (e.g. Application, Data Access Layer, and
Database) so you know it will all hang together.
Increasingly we live in a world where auditing is required.
Source control gives you an ability to know when a change was made, and by
whom. With the aid of a standard style of commit message, you can also know why
the change was made (perhaps a link to the support ticket or feature request?). Using Source Control provides you with a known truth for the database under development. Think how much time and worry it could save if you know exactly where to get all the database changes to implement, and you know that it's all being backed up for safe keeping should the worst happen.
By implementing Source Control you lower the barriers to implementing
deployment testing, perhaps within a continuous integration environment. This
means you can test your deployment on supported hardware/software
configurations and run a standard set of tests to give confidence in the
product. I’ve previously written about how to set this up.
Why doesn’t everyone use it already?
Whilst application developers have used source control for a number of years, it is relatively new to the database development scene, and as such the tools to make it easy have only started to appear in the last year or so. Database developers (and particularly DBAs who need to be on board) are often reluctant to leap to the latest change until it has been proven to be robust and reliable. This isn't a bad thing - new tools and ways of working take time to adopt, and you want to be sure you have the right one.
Adopting source control is a change to the toolset. You need therefore to be aware that it will take investment in the short term, to yield benefit in the longer term. Immediate benefits in terms of having a central location for all changes which can be easily backed up and rolled back is something often overlooked by those who haven't used such systems in the past.
Adopting source control is a change to the toolset. You need therefore to be aware that it will take investment in the short term, to yield benefit in the longer term. Immediate benefits in terms of having a central location for all changes which can be easily backed up and rolled back is something often overlooked by those who haven't used such systems in the past.
To get a change in the development practices and tools, you need a champion in the business - this is really important - because developer led
solutions rarely get the budget approval (in terms of time or money) to proceed. You do of course need a
development team that is open to it too!
In terms of costs, this will depend somewhat upon the size of your team, but more importantly the features that you want to deploy, and whether you go for a commercial or free product. There's no right answer here - but I suggest you start at the features you want, and go from there - the cost of a commercial product is offset by support, and the adoption costs of any source control systems should be quickly made back in terms of increased productivity and reduced errors. If you want to adopt the dedicated model (which I recommend to avoid conflict) then you'll need to think about a developer database installation - these can be quite cost effective, and may be covered by existing licensing (e.g. MSDN). You need to also think about licensing for a continuous integration server if you're going that way - it's often not included in the team's tooling licenses (but this could be done slightly later, once the team has become comfortable with source control). You need to budget some space for the code repository to live (and be backed up) as well as some time to manage the system - at least in its early days whilst things are settling down.
The most important side is probably the user side - but I have found that it is sometimes helpful to try it with a small group first, to allow any problems with workflow to be picked up and the tooling choice confirmed.
Overall
Why not try it? You can adopt it in stages - perhaps start using it only on a new project, or run source control in parallel with your current arrangement. The business benefits of having a more robust development process are clear, particularly where you have many flavors of your product. It allows a better isolation between development and production (important for certain industries).
Source control is rapidly becoming a must have for database developers, in the way that it as been for application developers for some time.
Source control is rapidly becoming a must have for database developers, in the way that it as been for application developers for some time.
Win a Red Gate Source Control license!
If I haven’t convinced you that it’s a better way to work –
why not find out for yourself for free? Red Gate have kindly provided 5 licenses for their Source Control product to give away! Red Gate's Source Control software is an interface with SQL Server Management Studio, to give a user friendly way of scripting out all of your changes and checking them into your source control system, as well as implementing others' changes in your database. It can work with Subversion (GPL), TFS, Vault, as well as many other systems you may already have (I've used it with Accurev), or even to a file location, to allow you to try out source control for databases in your environment.
To be in with a chance of winning, simply tweet a link to this post and leave a comment below, including your twitter handle so we can contact you. For example, why you think that database source control is a good/bad idea? Why not detail your experiences - good or bad - of using or adopting source control for databases? If you don't leave your twitter handle you can't win - sorry!
Because there's no right or wrong answer - it's all based on your viewpoint - this is a prize draw. You can enter until 26th October 2012 (23:59 BST).
To be in with a chance of winning, simply tweet a link to this post and leave a comment below, including your twitter handle so we can contact you. For example, why you think that database source control is a good/bad idea? Why not detail your experiences - good or bad - of using or adopting source control for databases? If you don't leave your twitter handle you can't win - sorry!
Because there's no right or wrong answer - it's all based on your viewpoint - this is a prize draw. You can enter until 26th October 2012 (23:59 BST).
