The Skill of Releasing Software
I opened this topic yesterday and received valuable responses from many readers. Scott wrote a lot, so that’s all I have room for today. Here is what he says:
As someone who has recently co-lead a mission-critical software project through two major releases successfully, including a complete hardware replacement/virtualization plus Windows Server and SQL Server upgrades and seen two nearby project teams have real problems releasing smaller changes, I will offer just a couple of thoughts:
1. You’ve got to start with and keep a clean architecture. Deployment risk, I think, increases more than linearly, maybe exponentially, with overly complex architectures. Never add a bad enhancement design to a good architecture, and do insist on improving a existing bad architecture before or while adding to it. (Read the many good books on refactoring including database refactoring.) Ambitious developers and shortsighted managers sometimes lose sight of the importance of quality code, but if you won’t do this for me, the guy who seems to always have to come in and fix other people’s code, then do it for yourself, since you might have to actually maintain your own architecture.
2. Practice your deployments! You should get at least one, preferably more, without any glitches.
2a. Plan your deployments! You should have a clear, stable checklist listing all details that has led to a successful
practice deployment starting from a snapshot of production. Along with as many steps as possible saved into command scripts ahead of time.
2b. To ensure your production deployment matches your practice deployment make sure you’re testing environment configuration matches your production environment config.
3. Believe in and embrace code freezes and code stability! If you are nearing a deployment and you look around and all the programmers are heads down banging away on code changes, sorry, you are NOT ready for or near the deployment! You can’t expect a fast-forward development effort to turn into a successful deployment overnight, any more then you can expect a bunch of track runners to run up to the tape at full speed, stop on a dime without slowing down first, and not fall all over the place.
4. Embrace development tools that support deployments! For database deployments I swear by the Redgate tools.
5. Improve your testing and your test tool environments, including embracing automated unit testing and builds. Check out Elfriede Dustin’s books on software testing techniques.
6. If possible, deployment testing and deployments are a great time for "pair programming"–that is, a second pair of eyes on every aspect. For our deployments the four of us had overlapping ownership areas and during our final production deployments we each had our tasks to do while the other three observed, once in a while catching an imminent error or remembering a forgotten detail.
Do you agree with Scott? Do you have other insights you would like to bring into the conversation? Share it with us by writing btaylor@sswug.org.
Cheers,
Ben
SSWUGtv
With Stephen Wynkoop
Click here if you missed the interview on Security Key Management.
Townsend Security: Key Management 101, Lesson one — Always protect the key!
$$SWYNK$$
Featured Article(s)
Partitioning Relational Data – (Part – 3)
This is the third part of the three part article series on partitioning relational data. In this part of partitioning relational data article series, I’ll discuss why we might want to partition multidimensional data, overview of SQL Server partitioning architecture, and guidelines for partitioning relational and multidimensional data.
Featured White Paper(s)
Go Beyond Basic Up/Down Monitoring
read more)
Featured Script
dba3_FirstLastTriggerOrderInformationIsIn_SysObjects_Status_Demo
sp_settriggerorder can be used to set a trigger as "first" or "last". sp_helptrigger doesn’t return this information about tr… (read more)