Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase ««12

Developer Pressure Expand / Collapse
Author
Message
Posted Friday, September 6, 2013 3:30 PM
SSC Eights!

SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!

Group: General Forum Members
Last Login: Today @ 5:12 PM
Points: 860, Visits: 1,116
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.
Post #1492438
Posted Friday, September 6, 2013 8:09 PM


SSChasing Mays

SSChasing MaysSSChasing MaysSSChasing MaysSSChasing MaysSSChasing MaysSSChasing MaysSSChasing MaysSSChasing Mays

Group: General Forum Members
Last Login: Tuesday, September 23, 2014 7:42 PM
Points: 635, Visits: 2,215
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.
Post #1492466
Posted Friday, September 6, 2013 9:02 PM
SSC Rookie

SSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC Rookie

Group: General Forum Members
Last Login: Thursday, September 12, 2013 12:37 AM
Points: 35, Visits: 121
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!
Post #1492468
Posted Saturday, September 7, 2013 4:28 PM


SSCertifiable

SSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiable

Group: General Forum Members
Last Login: Sunday, October 19, 2014 11:12 AM
Points: 7,791, Visits: 9,545
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
Post #1492566
Posted Wednesday, September 11, 2013 4:09 AM


SSCertifiable

SSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiable

Group: General Forum Members
Last Login: Today @ 11:15 AM
Points: 5,587, Visits: 3,438
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!!!
Post #1493547
« Prev Topic | Next Topic »

Add to briefcase ««12

Permissions Expand / Collapse