June 1, 2015 at 8:19 pm
Comments posted to this topic are about the item Finding Production Drift
June 2, 2015 at 7:13 am
At least we are pretty good at this. We use Subversion for our code repository, track all changes to production, both code and direct data change. We even have the multiple development, testing, and staging environments. Where we struggle is getting the sufficient testing done that we should. There just aren't enough people or enough time. We haven't been able to make an automated testing system really work for us. So we do the best we can and have hot fixes.
June 2, 2015 at 7:49 am
When starting working on a modification to a stored procedure, I start by comparing what's in production to the latest in the production branch of the source code repository. They should match, but not always. For example, a deployment to production may get rolled back to prior release, or a developer may check their work under the wrong branch. Unless team members are very diligent, and there is a designated SCC administrator, then the source code repository is just a collection of shared folders containing versioned files (which is still useful), rather than being an actual system of record (the ideal).
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
June 2, 2015 at 1:05 pm
We handle this using a "build the tunnel from both ends" approach.
Ideally anything that gets done gets pushed through our continuous deployment system, and we can push those through in a couple of hours, but to make sure we keep up with changes in prod, especially data changes to metadata that might be happening through configuration tools, we also push scrubbed and sampled prod data back to our dev environments weekly.
June 2, 2015 at 1:54 pm
There is a mantra of "If it hurts do it more often". The meaning of which is that if you have to do a task over and over again you will soon turn your mind to ways of making it less painful.
I am fully converted to the idea of committing local changes which are adequately tested to VCS and having an automated build pipeline deploy to the appropriate shared environment. It really does make life one hell of a lot easier.
I've heard an awful lot of "we can't do that because....". I would recommend devoting some time to thinking about the "because". Sometimes a bit of thought leads to solutions that you wouldn't normally consider. "We can't do that because..." is Maginot line thinking.
Viewing 5 posts - 1 through 4 (of 4 total)
You must be logged in to reply to this topic. Login to reply