SQL Clone
SQLServerCentral is supported by Redgate
 
Log in  ::  Register  ::  Not logged in
 
 
 


Developer Pressure


Developer Pressure

Author
Message
cdesmarais 49673
cdesmarais 49673
Ten Centuries
Ten Centuries (1.3K reputation)Ten Centuries (1.3K reputation)Ten Centuries (1.3K reputation)Ten Centuries (1.3K reputation)Ten Centuries (1.3K reputation)Ten Centuries (1.3K reputation)Ten Centuries (1.3K reputation)Ten Centuries (1.3K reputation)

Group: General Forum Members
Points: 1255 Visits: 1423
We're mostly CI and being pushed strongly towards CD, and I am just starting to think through some of the challenges. DB changes are seen as a major block to CD, and it does create some friction with some developers. Unfortunately databases are pretty much the anti-pattern for CD, they are shared across multiple teams, require specialized knowledge to code for properly, etc. A couple of issues I'm thinking about in particular are...

Performance: Databases in most systems are single point bottlenecks, so a single poorly performing query can have system wide effect in a way that most app code can't. Performance tests in general are a tricky part of CD, and database performance testing is trickier than most. This isn't just about queries. Adding a not null column to a table that has 10,000 rows in a developers environment probably won't even flag as an issue, but will turn into an unpleasant evening when the same script is deployed to the production system with 100 million rows.

Rollback: Rolling back code is easy. Rolling back data changes is really not. I was just reading a very well known book on the subject where they suggested "always make sure to backup your database" as a way to handle rollbacks. I almost threw the book down because of how fundamentally wrong headed that is. If I have to take a downtime long enough to restore one of our big db's from backup, I'm going to be unemployed. Rollback strategies for destructive data changes require careful planning and often keep both versions available for some period of time, using triggers, hiding through views, etc.

Not to suggest that there aren't others. I think my first bite at the agile apple will probably be to instrument db deployments in a performance environment in order to capture slow scripts.
Jim P.
Jim P.
SSCommitted
SSCommitted (1.9K reputation)SSCommitted (1.9K reputation)SSCommitted (1.9K reputation)SSCommitted (1.9K reputation)SSCommitted (1.9K reputation)SSCommitted (1.9K reputation)SSCommitted (1.9K reputation)SSCommitted (1.9K reputation)

Group: General Forum Members
Points: 1859 Visits: 2215
cdesmarais 49673 (9/6/2013)
...

Rollback: Rolling back code is easy. Rolling back data changes is really not. I was just reading a very well known book on the subject where they suggested "always make sure to backup your database" as a way to handle rollbacks. I almost threw the book down because of how fundamentally wrong headed that is. If I have to take a downtime long enough to restore one of our big db's from backup, I'm going to be unemployed. Rollback strategies for destructive data changes require careful planning and often keep both versions available for some period of time, using triggers, hiding through views, etc.


A lot of our app changes were government drop-dead changes for HIPAA/Medicare changes. So the developers were directed to get the government changes in and correct. The subtle/user-ease fixes were dumped on the ground.

I was able to totally change the QA process when they moved the DEV team from Washington state to Ohio. Part of that was I build a DEV/QA silo that was based off three month behind the production DB. When they started doing second stage testing on that and it operated like crap, we started getting better code efficiency.

I never had to restore the DB for production systems. But I had a clue from the test environment. The developers knew better and we basically always worked out the door.



----------------
Jim P.

A little bit of this and a little byte of that can cause bloatware.
wayne_hudson3
wayne_hudson3
Valued Member
Valued Member (54 reputation)Valued Member (54 reputation)Valued Member (54 reputation)Valued Member (54 reputation)Valued Member (54 reputation)Valued Member (54 reputation)Valued Member (54 reputation)Valued Member (54 reputation)

Group: General Forum Members
Points: 54 Visits: 125
The car industry tried this.

"Put it together as quickly as we can and let the consumers find the problems for us".

Then the Japanese moved in and the rest is history!
Tom Thomson
Tom Thomson
One Orange Chip
One Orange Chip (26K reputation)One Orange Chip (26K reputation)One Orange Chip (26K reputation)One Orange Chip (26K reputation)One Orange Chip (26K reputation)One Orange Chip (26K reputation)One Orange Chip (26K reputation)One Orange Chip (26K reputation)

Group: General Forum Members
Points: 26092 Visits: 12500
Continuous development, continuous unit test, continuous integration, continuous system test, continuous QA, continuous release, and continuous deployment are all great concepts, and they work extremely well, as long as everyone remembers that it's no good shoving something out the door if it doesn't work - and that means that you've got to ensure that salesmen, marketeers (and managers in development, integration, QA, or operations chasing a bonus for quick work) can't hijack the process to achieve their personal aims. That's the only difficult part of continuous development, release and deployment - and it's really difficult, unless you can get the CEO onside.

And of course it isn't really continuous: it isn't even high frequency discontinuous: you are not going to be deploying a new system every 5 microseconds; it's incremental - and the people who pioneered it way back when called it incremental integration, validation, and release. And how often increments are deployed will vary - several increments in development and unit testing may turn into one larger increment in integration and QA, and several QA increments may turn into one release (I tended to try to avoid that happening when I was in charge), and not all releases will be deployed for every customer (ok, that could cause issues for customer support if you didn't keep good records of what went where and did let crud get out the door).

I haven't seen it put developers under extra pressure; in fact when properly managed it causes much less developer pressure than outmoded operating models like the waterfall.

Tom

Gary Varga
Gary Varga
One Orange Chip
One Orange Chip (27K reputation)One Orange Chip (27K reputation)One Orange Chip (27K reputation)One Orange Chip (27K reputation)One Orange Chip (27K reputation)One Orange Chip (27K reputation)One Orange Chip (27K reputation)One Orange Chip (27K reputation)

Group: General Forum Members
Points: 27334 Visits: 6550
CI is essential in modern software development. It is completely independent of CD in that you can get the benefits of CI without CD. Also CD doesn't necessarily mean that you release all successful builds deployed. CD can be to an internal/preview server. The key thing is that CI ensures that what you develop builds (and passes the tests you have created) whereas CD ensures that your successful builds deploy successfully. Deploy does not necessarily mean release.

As for devs? It is good for us. Only those that try and hide behind distant milestones, where it can be difficult to see who has done what, will be under significantly more pressure. Good. Everyone else can get satisfaction from progress and near immediate feedback.

The one caveat I will mention is that "it depends". This time it is how the project is managed.

Gaz

-- Stop your grinnin' and drop your linen...they're everywhere!!!
Go


Permissions

You can't post new topics.
You can't post topic replies.
You can't post new polls.
You can't post replies to polls.
You can't edit your own topics.
You can't delete your own topics.
You can't edit other topics.
You can't delete other topics.
You can't edit your own posts.
You can't edit other posts.
You can't delete your own posts.
You can't delete other posts.
You can't post events.
You can't edit your own events.
You can't edit other events.
You can't delete your own events.
You can't delete other events.
You can't send private messages.
You can't send emails.
You can read topics.
You can't vote in polls.
You can't upload attachments.
You can download attachments.
You can't post HTML code.
You can't edit HTML code.
You can't post IFCode.
You can't post JavaScript.
You can post emoticons.
You can't post or upload images.

Select a forum

































































































































































SQLServerCentral


Search