Patterns without Developers: Spa conference workshop
•
I did a workshop at the fantastic Spa conferencee this year. The purpose was to try and gather patterns in the software development process that didn't come out of the GoF book or PoEAA.
This is the output from those sessions, so late that I will at least do time in purgatory, if not someplace else. The session went OK. The slides didn't match the handouts and I managed to invite some heckling, but I was quite pleased to see everyone get down to work and start making patterns. The paper forms I got back didn't really get as much detail as my shepherd and I anticipated; and I'm giving some names and embellishing where appropriate. Comments below each one.
Name: Embedded Test Team
Definition: Separate teams mean handovers which always impede progress. Instead, embed testers with development team.
Big teams encourage silos and specialisation. Specialists are important but in this pattern you put them right where they are needed.
Name: Blue-green deployments
Definition: On deployment, delay to the slave server of a master/slave pair and then switch traffic routing
Intent: Keep production live at all times. No downtime on release.
The name of this pattern comes from Continuous Delivery [ Get the eBook *]
. It really depends on patterns like Encapsulate Table With View, or a NoSQL database to ensure that you can deploy two application versions at once without causing one to throw database related errors. The most successful use of this was on a project where the client insisted that we use stored procedures to access the database. While it was a big productivity hit for the developers, there were seconds of downtime when we released a new version. [more patterns in Refactoring Databases (eBook)<img border=0 width=1 height=1 src="http://ad.linksynergy.com/fs-bin/show?id=hdK31Ny9YPU&bids=145238.1639474&type=2&subid=0" *]
Name: Cookie Cutter Servers
Definition: Deploy servers as images or automatically built machines, rather than manual or evolved installations.
Intent: Keep consistency between different servers both in production and in test.
If you look for deployment related technical jobs, many of them would have you trying to enforce consistency on different environments, all of which are maintained by hand. This is nuts. Automation is your friend.
Name: Simplicator (Freeman / Pryce)
Definition: Define your own API that can be implemented by a stub for testing or by an adapter,
Intent: Decouple service consumers from providors to make testing more deteministic.
This is published in Growing Object-Oriented Software, Guided By Tests [eBook*]
Name: A/B Deployment
Definition: Continuous deployment to a limited subset.
Intent: Gauge whether new version is an improvement on the old before committing all users.
Applicability: Requires ability to operatemultiple versions in parallel. (Interface versioning!)
Timothy Fitz covered this, but I'm stealing the name from Split Testing until I find a better candidate.
Name: Virtualisation
Definition: Combine VMs to simulate systems in the operational environment
Intent: Create a scale model of the production environment for functional testing.
Motivation: An operational test environment is needed for end-to-end testing with all external systems that the software has to interface to,
Applicability: Operational procedures, testing of response to various events.
I know quite a few people who work as developers at banks. It takes six months to get a server approved and delivered to the point that you can use it, but a mere matter of weeks to get a virtual machine done. That's reason enough to do it. Let alone the ability to manage change and develop against realistic hardware. This becomes more compelling if you run Linux on server and desktop and can deliver virtualised nodes without the added hoops of licensing. You might get a VM in days if you carry on like that.
Name: Time Slicing
Definition: Bring down test environments when their testing time-slot is past.
Intent: Reuse test hardware for maximum utilisation of the investment
Applicability: Testing reqirements are sporadic and can be resource-levelled over time
Usage: Relies on virtualisation.
The group that made this and the previous pattern were on fire. Another benefit of virtualisation is stopping the horrid project delays because someone has booked out a test environment for months. You'd think that a major constraint like that would be part of the project planning process, but I find that most organisations prefer to have projects managers duke it out, fight-club style.
Name: Stubs
Definition: Ensure a system is tested againststubs and other systems in the environment before it is tested in a full pseudo-production environment.
Stubbing out external services can rock. It's all about feedback. If your code fails talking to the stubbed services, it's not ready for primetime. Why wait until you manage to get your app deployed (a battle in it's own right in big environments).
Name: Atomic deployment
Definition: Ensure that your deployment is transactional: either everything gets deployed, or nothing.
Intent: Ensure that everything that needs to be deployed is deployed or nothing.
Harder than you'd think to get going (can you really roll back that database change? what's the risk of doing that?) but worth the effort. Artifacts of a failed deployment can cause things to break in ways that are difficult to diagnose.
Name: Configuration Repository
Definition: Eliminate embedded service identifiers, addresses, sizings.
Intent: Abstract parameters out to a configuration service so that:
- It’s easier to manage
- the identical software can be deployed to every environment without adapting.
This pattern has been talked about for a very long time but not often done. Chris and Tom had a go with Escape, and you could probably do a decent job with couchdb. Not having to deploy configuration to each node: priceless.
Name: Synchronised release schedules
Definition: not given
I'm not sure what this was in aid of. If you have dependencies between different applications then you should be managing releases at the programme level. Sadly, many people don't do that.
Name: I know what you did last deployment
Definition:
Intent: -Get into a known state
-Automate what you do = consistency
-Version control is the key! Both deployed app and deployment script.
Pattern: 1. Mirror production
2. Automate deploy AND rollback
3. Tests against deployment automated
The group that did this struggled with trying to fit many patterns into one, I think. The key takeaways for me are the use of automation and version control. Which shouldn't surprise anyone - I think they were trying to address the disparity between the way we treat business code and the way we deploy it. Only recently have we seen anything like Joel Tests for this kind of thing.
* If you buy the ebooks via these links (and frankly in the year of the iPad, who's buying dead tree media?), then commissions go to my Kaffiene and Taylor Street Baristas habit. That's right, you're financing my drug dependency.