Source Control Vs Email -- Are you serious ????
-
This is a really stupid question , but I want to get some opinions and I'll explain why.
As a DBA , would you execute scripts provided to you via an email or would you push back for a location in source control like tfs, svn etc. Naturally we are dealing with mission critical databases. My focus here is on would to bypass the process meant to protect the database because you trust the sender ( I know he's a good guy) and just want things to speed up to meet deployment deadlines.
I am trying to convince few managers in my current org. that when it comes to database deployments the label checked into source control trumps files extracted from a location in TFS and sent via email. Another thing I am trying to settle is when performing a release you should label it instead of simply branch the Sourcecode.
Branch + label would be great but label is a must.
-
If some form of source control is in place then that must be the only source used for code. When someone sends a version of code via email, no matter how reliable they are you don't know that is actually the current version of the code. Somebody else may have changed it between your sender getting a copy, doing whatever they did to the code and then sending it to you. Been there, been severely bitten by it and wouldn't let it happen again.
Personally, labelling the source control is preferable, purely because there is a definite 'mark' across the database which is easier to retrieve from.
-
My focus here is on would to bypass the process meant to protect the database because you trust the sender ( I know he's a good guy)
Are you kidding me. :w00t: The process is not only to safeguard the database but to manage code as well. It's very difficult to manage (track changes) the code if not baselined on some version control tool. You can’t follow the mail chain for that.
-
I would go a step further and not only have source control but also a change management process to ensure any code going into live has been fully tested when moving through your environments. This will give you an audit trail so you can see who tested it and if there were any problems.
If you haven't got a change management application / no budget you could start off with something as simple as spreadsheet or build a small app to do this, at least that way you'll know where it's been tested and who tested it!
Cheers
Vultar
-
Would you believe it If I told you we have all this in place , code travels thru 5 environments before it reaches LIVE ( not always tested 🙂 but that's another issue).And we use VS 2010 and TFS for source control.
We have a team that are focused only on CM as well.
So where is the problem ???
-
Naturally we are dealing with mission critical databases. My focus here is on would to bypass the process meant to protect the database
I guess the problem is in this statement.
Two contradicting phrases: mission critical databases and bypass the process to protect the database
-
The solution is rather simple. You have defective human beings. If you simply find and eliminate them, your workflows will probably recover in a suitable manner.
-
probably not the same situation Jayanth, but at our shop the developers email code to the DBA all the time...
but from there the code it tested agaisnt the dev version of the database,a nd if it passes that prelim inspection, it gets bounced back for corrections or checked into TFS as part of the latest change script.
That official changescript has to go thru repetitive testing,a dhten is tested by the QA group seperately, before it's offered as the final script ready for release.
that's not the same as what you are saying, where someone is trying to bypass the typical channels to meet deadlines, but just an FYI on how things get done here; it sounds my step is already in your change control at a very early point.
Lowell
--help us help you! If you post a question, make sure you include a CREATE TABLE... statement and INSERT INTO... statement into that table to give the volunteers here representative data. with your description of the problem, we can provide a tested, verifiable solution to your question! asking the question the right way gets you a tested answer the fastest way possible! -
Jayanth_Kurup (10/13/2011)
Would you believe it If I told you we have all this in place , code travels thru 5 environments before it reaches LIVE ( not always tested 🙂 but that's another issue).And we use VS 2010 and TFS for source control.We have a team that are focused only on CM as well.
So where is the problem ???
The problem is allowing people to circumvent the code control process. I see it all of the time when deadlines approach - get the code in as quickly as possible because it is important to the release or the customer is screaming or a manager somewhere thinks they are more important than the processes in place.
If this is a regular problem then they need to look at the processes they have to see if they are suitable. Or they need to realise that the processes are there for a very good reason and something else needs to change - generally the deadline. Do you see more errors when the process is bypassed, either immediately or later when no-one can find the correct version of code?
-
I see it all of the time when deadlines approach - get the code in as quickly as possible because it is important to the release or the customer is screaming or a manager somewhere thinks they are more important than the processes in place.
Very true.
they need to realise that the processes are there for a very good reason
Right again.
something else needs to change - generally the deadline
I am afraid, this is the most difficult thing to do.
-
As I expected we all agree on the right way of doing things and the reasons. Unfortunately this is what was done and we faced an issue in LIVE. It was rectified; but I feel if only the DBA had pushed back we would not have been in this situation in the first place.
Thanks all for your input.
-
Jayanth_Kurup (10/17/2011)
As I expected we all agree on the right way of doing things and the reasons. Unfortunately this is what was done and we faced an issue in LIVE. It was rectified; but I feel if only the DBA had pushed back we would not have been in this situation in the first place.Thanks all for your input.
This sounds a lot like lessons we keep having to hammer home in my shop. Processes are what you run TO (i.e. lean on) when stuff goes sideways, and NOT what you run away from when stuff goes bad. In other words - if you have the right process then it's the fastest and best way to get things into production, and not the thing you bypass when a hitch comes up.
----------------------------------------------------------------------------------
Your lack of planning does not constitute an emergency on my part...unless you're my manager...or a director and above...or a really loud-spoken end-user..All right - what was my emergency again? -
I love this one 🙂
Jared
Jared
CE - Microsoft
Viewing 13 posts - 1 through 12 (of 12 total)
You must be logged in to reply to this topic. Login to reply