January 30, 2016 at 1:02 pm
Comments posted to this topic are about the item What is the True Version of Code?
January 30, 2016 at 3:37 pm
From the Article:
Instead I'd say that production changes should always be fed back to the VCS.
If anyone is actually doing it that way, they need to prepare to fail some of the newer audits. I've never allowed a "production first" change. Even in a dead panic, any and all database code has to have a second set of eyes look at it (abbreviated peer review), sign off on it, and the person who wrote it cannot promote it. And, yes, it's checked into source control as part of the sign off and, of course, is signed off on the ticket that MUST accompany the change. We're strictly NVO (No Verbal Orders) on database changes. Even I obey (I better... I wrote the company standard for such things) those same rules and I'm the DBA!
Our normal processes follow a similar pattern with a few more steps for QA and UAT. Our "gotta fix it now!" procedures are usually identical but at a greatly accelerated rate. The Dev Manager and the Business owner must sign off on "dead panic" changes to sometimes skip the QA and UAT but the two man rule for review and promotion cannot be bypassed. Always remember that your biggest mistakes usually occur when you're in a panic.
And I have to tell you, all the auditors, our customers, and the occasional lawyer love that we say what we're going to do, do exactly that, and have a documentation, audit, and approval trails for almost everything (trips to the can are excluded ;-)).
--Jeff Moden
Change is inevitable... Change for the better is not.
January 31, 2016 at 12:25 pm
For each revision to a DDL script, prior to check-in, I include a new entry in the header with the date, with CO number, developer's name, and brief one line description. When submitting a change order for deployment to UAT or Production, I will branch off a copy of associated DDL scripts to a release folder named after the same CO number. This version control folder is what gets referenced in the CO details. Therefore, in the event that the production data needs to be restored, there is no ambiguity about what release is currently in production, what the change was, or what deployments occurred over a period of time.
It's also useful to perform a difference comparison between production against what's contained in the CO release folders, which can confirm the presence of any "BlackOps":-) deployments that may have occurred outside the sanctioned change control process. Likewise, developers starting a new project or CO can compare the latest version under release against what they believe to be the latest under development.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
February 1, 2016 at 6:13 am
I'm with the DBA: the true version of code is what's in Production.
And if your development and release processes are strict enough, the version in SC will match what's in production.
Despite Jeff's comments, I think that there will be plenty of environments out there which cannot afford the luxury of going through a proper peer-review process for all changes (eg, it's 3.30am and the cube load needs to be ready by start of business – there's already one sleepy on-call developer working on this, the second might be sick or on leave).
So there must be a process for feeding emergency changes back into SC after the fact in these cases.
If you haven't even tried to resolve your issue, please don't expect the hard-working volunteers here to waste their time providing links to answers which you could easily have found yourself.
February 1, 2016 at 7:07 am
"a DBA say that the true version of the code is always in production."
Hmm, I heard this claim before. However, the production version was broken.
February 1, 2016 at 7:21 am
null
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
February 1, 2016 at 7:22 am
2000t (2/1/2016)
"a DBA say that the true version of the code is always in production."Hmm, I heard this claim before. However, the production version was broken.
The thing is, in most IT organizations, the business and development teams don't care what the DBA thinks regarding which version of the stored procedure is true. As far as they're concerned, the DBA is just a canky gray-haired over-paid troll who lives in the server room and who's primary responsibility is keeping the servers running and deploying the code they're given. So long as the procedure compiles and doesn't break anything, they don't want feedback.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
February 1, 2016 at 7:26 am
2000t (2/1/2016)
"a DBA say that the true version of the code is always in production."Hmm, I heard this claim before. However, the production version was broken.
So what? It's still the true version.
If you haven't even tried to resolve your issue, please don't expect the hard-working volunteers here to waste their time providing links to answers which you could easily have found yourself.
February 1, 2016 at 7:36 am
Define 'true'.
The production code - the code the DBA pulls from the server - is just that. The code currently in production. It ~should~ match one of the versions in source control but it shouldn't be outside of it.
The current code - the code that is at the current state of development - is what the code will be. That's also true code.
So the question is more what your organization's definition of 'true' is regarding code.
I dislike anyone who bypasses source control and pulls from the database unless it's to check what version is running. That's the path to uncontrolled code.
February 1, 2016 at 8:15 am
We all know it's the DBA who ultimately calls the shot regarding these important decisions; right?
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
February 1, 2016 at 8:44 am
I think I might have said those words about the true code. I'm all for having code in VCS, all for solid change management. Most orgs I have worked with do both, but imperfectly. Doing it perfectly is harder than most orgs seem ready to tackle, or able to justify. Cynical/lazy? Maybe. I think it comes down to this; are we not doing it because it's hard/complicated, or because we just don't know how to do it well and thus avoid it?
February 1, 2016 at 12:04 pm
"Certainly hot fixes need to occur, and there are times that you can't wait for a set of changes to be made in development, tested, approved, and then deployed to production."
Instant fail.
You NEVER EVER EVER put a change into production without going through development/QA/approval/whatever.
NEVER.
There's a reason for the triune environment and it's pure BS to violate it, be it pressure from C-Level or your own manager, violation of testing is a good way to destroy something important, no matter how seemingly trivial the change might be--even so much as adding a new index.
If there's a problem that "must bypass testing to deploy it now" your entire development system is just one mistake away from complete and utter devastation of your company.
This is the kind of corporate negligence that needs stop. period.
(Can you tell I'm a fan of testing production changes? :hehe:)
February 1, 2016 at 12:15 pm
Phil Parkin (2/1/2016)
I'm with the DBA: the true version of code is what's in Production.And if your development and release processes are strict enough, the version in SC will match what's in production.
Despite Jeff's comments, I think that there will be plenty of environments out there which cannot afford the luxury of going through a proper peer-review process for all changes (eg, it's 3.30am and the cube load needs to be ready by start of business – there's already one sleepy on-call developer working on this, the second might be sick or on leave).
So there must be a process for feeding emergency changes back into SC after the fact in these cases.
+1
I wouldn't want to be the second person to get called at 3:30 AM just to peer-review some coding changes.
-------------------------------------------------------------
we travel not to escape life but for life not to escape us
Don't fear failure, fear regret.
February 1, 2016 at 12:25 pm
roger.plowman (2/1/2016)
"Instant fail.
You NEVER EVER EVER put a change into production without going through development/QA/approval/whatever.
NEVER.
Here is the reason I would NEVER EVER want to be on call for this type of environment. If you want me on call, and it's 3:30 AM and some code needs fixed for a cube that has to be available at 8 AM, then I'm either going around these steps, or you can fire me. 😎
the VCS topic - Oh how I've missed you, NOT!!!
-------------------------------------------------------------
we travel not to escape life but for life not to escape us
Don't fear failure, fear regret.
February 1, 2016 at 12:52 pm
One reason why the production version of some objects can differ somewhat from the latest in development source control is that the DBA may perform some last minute adjustments to DDL scripts prior to deployment. For example, the DBA may supply a forgotten USE <database> statement, modify the table space / file group location clause, or grant additional permissions. If these minor (but important) modifications arn't looped back to the development team post-production for inclusion in the latest sourced version of the script, then it gets lost between releases.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
Viewing 15 posts - 1 through 15 (of 99 total)
You must be logged in to reply to this topic. Login to reply