February 1, 2016 at 1:33 pm
VCS needs to be taught in College and on Day 1 of onboarding in a new job. I find that with application developers (by apps I am targeting compiled apps like C#, Java, etc.) are more disciplined with this because these application's deployment requirements lend themselves well to having a VCS come first in the SDLC. What I mean by that is that a C# class definition is not something that is typically deployable in and of itself. By nature, to be useful, it needs to be compiled as part of an application codebase with other classes on a workstation or build server and then be deployed as a compiled executable or dll to an application server.
However, for us database developers (not that we aren't also app devs but have to make a distinction somehow) our code is discrete and can be modified, stored deployed outside the scope of any application or even without regard to re-building other objects on the target database. What I mean by this is that a stored procedure can be scripted from a Dev instance, modified, and then immediately deployed to a Prod server. That procedure change does not need to go through any build and deploy process outside of the database (i.e. the hosting) that it is being compiled against to make the procedure useful to the database or caller.
For the app devs VCS almost becomes compulsory if they want a chance to ever redeploy a new version of their app because it is not as if one can easily "script out" a class definition from a deployed executable or dll sitting on a web/app server. Decompilers are neat and have come a long way but this is not the app dev's chosen model for making changes due mostly to these compilation restrictions. On the other hand, database folks have no such restrictions. A database dev can connect to a database, script out the latest procedure, make a change, and compile that change into the system...and therein lies the trap! If one is not compelled to do something by a system constraint then many times they will choose not to. Even experienced and good developers will come up with solid reasons, some arguably even defendable to and eventually accepted by management, not to start with VCS for every change. If it can be done, someone will do it.
Without policy and procedure the practice of developers slamming database changes into production (or referring to production as the Gold Copy) will be commonplace because the deployment model lends itself to that kind of treatment. Regardless of which color you like getting everyone to drink the Kool Aid is step 1. If you want to treat Prod as the Gold Copy go for it. With a tight dev team that communicates on every point that can work. I go for VCS because I like the traceability and version history aspects. If you try and have dissenters on the team that argue VCS is not the "real" Gold Copy they must eventually make a concession to use it despite their beliefs otherwise you see drift. It's all about everyone looking and moving in the same direction.
There are no special teachers of virtue, because virtue is taught by the whole community.
--Plato
February 1, 2016 at 2:17 pm
Jeff Moden (1/30/2016)
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..
So there's never been a case of a change made on production first?
Follow me on Twitter: http://www.twitter.com/way0utwest
Forum Etiquette: How to post data/code on a forum to get the best help
My Blog: www.voiceofthedba.com
February 1, 2016 at 2:18 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.
I tend to disagree in that the true version should be in a VCS, though I will note that sometimes it ends up in production. I'd like to see the time where we consider the true version in production to be as small as possible.
Follow me on Twitter: http://www.twitter.com/way0utwest
Forum Etiquette: How to post data/code on a forum to get the best help
My Blog: www.voiceofthedba.com
February 1, 2016 at 2:20 pm
Orlando Colamatteo (2/1/2016)
VCS needs to be taught in College and on Day 1 of onboarding in a new job. I find that with application developers (by apps I am targeting compiled apps like C#, Java, etc.) are more disciplined with this because these application's deployment requirements lend themselves well to having a VCS come first in the SDLC.
+1E+10
Follow me on Twitter: http://www.twitter.com/way0utwest
Forum Etiquette: How to post data/code on a forum to get the best help
My Blog: www.voiceofthedba.com
February 1, 2016 at 2:20 pm
Orlando Colamatteo (2/1/2016)
VCS needs to be taught in College and on Day 1 of onboarding in a new job. I find that with application developers (by apps I am targeting compiled apps like C#, Java, etc.) are more disciplined with this because these application's deployment requirements lend themselves well to having a VCS come first in the SDLC.
+1E+10
Follow me on Twitter: http://www.twitter.com/way0utwest
Forum Etiquette: How to post data/code on a forum to get the best help
My Blog: www.voiceofthedba.com
February 1, 2016 at 2:21 pm
roger.plowman (2/1/2016)
"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.
Whether it's a fail or not, it happens. If it happens once, then we need a process to ensure we capture those changes.
Follow me on Twitter: http://www.twitter.com/way0utwest
Forum Etiquette: How to post data/code on a forum to get the best help
My Blog: www.voiceofthedba.com
February 1, 2016 at 2:29 pm
I'm in agreement with most people that changes should go through development. I agree nothing should happen on production. I think that the true version of your code is what's in the VCS, because that's been tested. If you've made a change in prod, then it's certainly running, but it's wild code, and potentially a problem. If that happens, you feed it back into the cycle to be sure it's actually good code.
Here's the rub.
Let's say you have an issue in production with a proc/view/table/function. You want to test it. However development has changed. I can't necessarily make the test in dev because I don't have a valid environment in which to test. Same for test/Qa/staging. What do I do?
Maybe I can deploy a new copy of the db that looks like production, but maybe I cannot. I should be able to, and this is one of the reasons that having a DevOps process to reset a new environment is important.
However, I may change things in production, then I need to get that into a VCS as an emergency change (for a log) AS WELL AS get this change into dev somehow. That might require some work, depending on the change, which may mean that I can't do it at 3am, but need to do it at 10am the next day.
If I'm changing data, that's sometimes even more of an issue as I don't necessarily have a good dev or customer service environment available to test. I might be able to do some testing, but I wouldn't necessarily have the same cycle I'd do elsewhere.
Bottom line, "true" may vary in your environment, and despite all your efforts, if you can't pop a new dev/test environment quickly to mirror production in some way, you may have production changes.
Follow me on Twitter: http://www.twitter.com/way0utwest
Forum Etiquette: How to post data/code on a forum to get the best help
My Blog: www.voiceofthedba.com
February 1, 2016 at 3:48 pm
below86 (2/1/2016)
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!!!
If you have to develop new code at 3:30 in the morning the whole development department needs to be fired. This is not a situation where new code *needs* to be created.
All testing should have been done long before deployment.
February 1, 2016 at 4:36 pm
roger.plowman (2/1/2016)
below86 (2/1/2016)
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!!!
If you have to develop new code at 3:30 in the morning the whole development department needs to be fired. This is not a situation where new code *needs* to be created.
All testing should have been done long before deployment.
Consider the possibility that a piece of rogue data hits your ETL pipeline and it errors out. The fast solution is to make a change to a proc to handle it and then restart the ETL. The slower solution is to fix the code properly and go through a thorough testing and release process (while explaining to the business why their analytics are out of date - assuming, of course, that you haven't been fired by then).
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 4:42 pm
I see roger.plowman as an idealist and Phil as a pragmatist in this debate...both of you are right and you both believe in using a VCS to store the Gold Copy. We need to cherish this common ground 😉
I say, even if you have to slam something into production you should still open the object from VCS, make the code change, unit test it (is this too much to ask, even in this scenario), deploy it (into all SDLC environments, not just into production) and then check it back into you VCS.
Then you tell the business "we're good to go forward" and then you spend the rest of the next morning doing the damn paperwork for what just took you 5 minutes to fix. Sound familiar?
There are no special teachers of virtue, because virtue is taught by the whole community.
--Plato
February 1, 2016 at 5:12 pm
Before making changes to SQL objects, I'm in the habit of updating my dev VCS from production, then checking for any changes that may have "slipped" in before starting my work. Hopefully they are perfectly in sync.
This way, I can be sure that the true version of the code is both production and VCS.
(yes we do get emergency code changes in production)
The REAL problem I have with "the true version" of the code is when there are multiple DEV branches under way and the releases are not unified, but separate - this can be a real pain to deal with.
A recent project involved major changes to a BI feed that would take months to complete, and while that development was ongoing, there were multiple smaller changes made to one stage of the feed and pushed to production, multiple times, which meant a constant process of merging the live changes with the development environment and starting the test cycle again for those stages. Horrible. Can't wait for it to end.
MM
select geometry::STGeomFromWKB(0x0106000000020000000103000000010000000B0000001000000000000840000000000000003DD8CCCCCCCCCC0840000000000000003DD8CCCCCCCCCC08408014AE47E17AFC3F040000000000104000CDCCCCCCCCEC3F9C999999999913408014AE47E17AFC3F9C99999999991340000000000000003D0000000000001440000000000000003D000000000000144000000000000000400400000000001040000000000000F03F100000000000084000000000000000401000000000000840000000000000003D0103000000010000000B000000000000000000143D000000000000003D009E99999999B93F000000000000003D009E99999999B93F8014AE47E17AFC3F400000000000F03F00CDCCCCCCCCEC3FA06666666666FE3F8014AE47E17AFC3FA06666666666FE3F000000000000003D1800000000000040000000000000003D18000000000000400000000000000040400000000000F03F000000000000F03F000000000000143D0000000000000040000000000000143D000000000000003D, 0);
February 1, 2016 at 5:36 pm
mister.magoo (2/1/2016)
Before making changes to SQL objects, I'm in the habit of updating my dev VCS from production, then checking for any changes that may have "slipped" in before starting my work. Hopefully they are perfectly in sync.This way, I can be sure that the true version of the code is both production and VCS.
Ye of little faith! I don't blame you but it tells me you might be up against some organizational challenges that have eroded your confidence in the VCS.
The REAL problem I have with "the true version" of the code is when there are multiple DEV branches under way and the releases are not unified, but separate - this can be a real pain to deal with.
A recent project involved major changes to a BI feed that would take months to complete, and while that development was ongoing, there were multiple smaller changes made to one stage of the feed and pushed to production, multiple times, which meant a constant process of merging the live changes with the development environment and starting the test cycle again for those stages. Horrible. Can't wait for it to end.
This is why a commitment to an SCM model and a clear and documented branching and merging approach adhered to by all and overseen by trusted servants (CM or deployment team or manager) is critical. Concurrent development happens in any org of a non-trivial size. There are lots of branching merging models that can handle it but everyone needs to be on the same page for things to work well. If even one person or team is doing their own thing away from the intended approach the whole thing falls apart.
edit: spelling
There are no special teachers of virtue, because virtue is taught by the whole community.
--Plato
February 1, 2016 at 6:56 pm
Orlando Colamatteo (2/1/2016)
mister.magoo (2/1/2016)
Before making changes to SQL objects, I'm in the habit of updating my dev VCS from production, then checking for any changes that may have "slipped" in before starting my work. Hopefully they are perfectly in sync.This way, I can be sure that the true version of the code is both production and VCS.
Ye of little faith! I don't blame you but it tells me you might be up against some organizational challenges that have eroded your confidence in the VCS.
Heh - I can tell you that a lot of people are "up against some organizational challenges" with both VCS and a lot of other things. Emergency code changes are a fact of life in every world I've ever lived in. Yes, a VCS that's perfectly maintained is an ideal situation, but I don't live in an ideal world.
This is why a commitment to an SCM model and a clear and documented branching and merging approach adhered to by all and overseen by trusted servants (CM or deployment team or manager) is critical. Concurrent development happens in any org of a non-trivial size. There are lots of branching merging models that can handle it but everyone needs to be on the same page for things to work well. If even one person or team is doing their own thing away from the intended approach the whole thing falls apart.
edit: spelling
Concurrent development on multiple branches that have not been unified can't be called current. If you have an emergency code change, there's no way to consolidate everything into one before making the change because they aren't complete yet. An emergency is just that - an emergency and, by its very nature, has to be dealt with immediately.
Would I love to live in the ideal world of a true VCS that's always current an no emergencies ever exist? Absolutely. Do I see it happening any time soon? No. I have a tremendous amount of respect for anyone who has that environment established. If you do, my hat's off to you.
February 1, 2016 at 8:10 pm
Ed Wagner (2/1/2016)
Concurrent development on multiple branches that have not been unified can't be called current. If you have an emergency code change, there's no way to consolidate everything into one before making the change because they aren't complete yet.
A good branching and merging model deals with all of your concerns. There is Gold, there is in-flight for various envs (dev, qa, uat, etc.) and there is a way to isolate and integrate all as needed to maintain the envs and honor the idea of Gold.
Would I love to live in the ideal world of a true VCS that's always current an no emergencies ever exist? Absolutely. Do I see it happening any time soon? No. I have a tremendous amount of respect for anyone who has that environment established. If you do, my hat's off to you.
I do. Believe it or not it is not too difficult to maintain. Getting there was very difficult, however, and required lots of coordination, training, advocacy and coaching to get the dev team and management to the point where it was fully realized and supported (read: culture-shift). It took about 3 years to go from no source control to full adoption and support. And yes, we have emergencies, just like every other shop, but recovering is not a reason for us to bypass the VCS because there is never a reason to bypass the VCS.
There are no special teachers of virtue, because virtue is taught by the whole community.
--Plato
February 2, 2016 at 12:18 am
Orlando Colamatteo (2/1/2016)
Ye of little faith! I don't blame you but it tells me you might be up against some organizational challenges that have eroded your confidence in the VCS.
Yes, challenges, more of that later...
Whether anything has eroded my confidence or not, I just believe in making sure. Every time.
This is why a commitment to an SCM model and a clear and documented branching and merging approach adhered to by all and overseen by trusted servants (CM or deployment team or manager) is critical. Concurrent development happens in any org of a non-trivial size. There are lots of branching merging models that can handle it but everyone needs to be on the same page for things to work well. If even one person or team is doing their own thing away from the intended approach the whole thing falls apart.
Yes, agreed, everyone needs to work together, but it is still a pain to deal with. Unless you have a magic wand that can decide whether code changes made by someone else affect your development path significantly, you still need to review the merge. Having a VCS does not remove the need for diligence and care, especially when there are multiple development branches.
Merging changes from multiple developments, for me, will always require extra time and effort to make sure they will "work" in my development. and that my development will not adversely affect the other branches. The VCS helps massively of course, which is why I always make sure I update my branch and review changes before I start another day's work.
I don't work in an environment where everyone involved in the systems is part of the same team and co-ordinates changes so it is up to me to make sure I am updating and merging as often as is required.
I will never rely solely on a VCS, just as a person working at height should not rely on the the safety checks of others - you wear safety equipment despite all the procedures and checks because life isn't perfect.
Don't get me wrong, I'm happy for you that your system works and no-one ever makes changes in Production that have not gone through the correct procedures, I just don't have that environment, and as a consultant on site, working for just one team, it is not part of my duties to re-shape my customers' procedures, so I work in a different way.
VCS helps a lot, but it's not a magic wand.
MM
select geometry::STGeomFromWKB(0x0106000000020000000103000000010000000B0000001000000000000840000000000000003DD8CCCCCCCCCC0840000000000000003DD8CCCCCCCCCC08408014AE47E17AFC3F040000000000104000CDCCCCCCCCEC3F9C999999999913408014AE47E17AFC3F9C99999999991340000000000000003D0000000000001440000000000000003D000000000000144000000000000000400400000000001040000000000000F03F100000000000084000000000000000401000000000000840000000000000003D0103000000010000000B000000000000000000143D000000000000003D009E99999999B93F000000000000003D009E99999999B93F8014AE47E17AFC3F400000000000F03F00CDCCCCCCCCEC3FA06666666666FE3F8014AE47E17AFC3FA06666666666FE3F000000000000003D1800000000000040000000000000003D18000000000000400000000000000040400000000000F03F000000000000F03F000000000000143D0000000000000040000000000000143D000000000000003D, 0);
Viewing 15 posts - 16 through 30 (of 99 total)
You must be logged in to reply to this topic. Login to reply