Enabling the Last Responsible Moment in Deployment

Posted by Amr Elssamadisy on Aug 12, 2009

Sections

Process & Practices,

Architecture & Design

Topics

Design ,

Architecture ,

Agile Techniques ,

Agile

Tags

Patterns

Chris Matts started a conversation with the following question:

One of the most powerful techniques I have used over the last three years is latent code patterns(lcp). The project I just left made every feature configurable. This meant that we never had the situation where a fix / feature had to wait for another feature in testing. We focused on fast and effective regression testing. Despite frequent diva releases we only ever had a single branch and had no code merging issues as a result.

Is anyone else using latent code patterns? I would like to hear how others do it as the best innovation comes from practitioners with a problem.

The other issue that lcp raise is the wip (work in progress) limit around testing. Thoughts?

Basically, what Chris was reporting is his team's ability to be able to turn on and turn off features at will. Therefore, even if a feature is in-progress, it does not block the team's ability to release at-will because the feature can be turned off.  Chris later stated the thinking behind this approach by sharing a question behind every design decision:

Does this (design) approach create a commitment?

 

David Roussel, also on the same team as Chris, clarified the technical details of exactly how their team implemented this approach. Later in the discussion, he  summarized the different ways others have implemented similar solutions:

I think there at lots of ways it can be done. But just realizing that we needed to be able to re-prioritize releases at the last minute, and that we could do it simply without branching was the big step. The rest is details, but interesting details.

How else have people solved this? So far we've had people mention:

• dependency injection, with dependencies changed at build time
• dependency injection, with dependencies overriden based on config
• plain old config and if statement
• branch per feature
• command document, command pattern,
• and database based command configuration (need a better name for this).

And Joshua Kerievsky added the following solution to the list:

David - we sometimes ship Commands to production that are still WIP, so no User will see them, yet we can execute them via a URL. Latent Commands?

I'm not sure if your list above includes the simple technique of just making a menu option invisible.

This design technique (or architecture if you prefer) is not new. In fact it pre-dates Agile software development and has many roots in the object oriented and patterns communities. The requirement it is fullfilling, i.e. Chris' question:

Does this (design) approach create a commitment?

is new, however.

 

1. Back to top

   How about run-time permission-based controls?

   by Cornelius Perkins

   One approach I've seen used is to exploit the permission system to turn features on and off.
   
   Once you've got a system which lets you determine, for example, which set of users are allowed to do which kinds of actions on which kinds of trades for which counterparties, you've got the ability to decide who gets access to new feature X.
   
   No rebuild, no config files.

   Reply

2. Back to top

   hard to implement

   by Andreas Kleffel

   3 simple flags would be sufficent:
   - Mock
   - Beta
   - Production
   
   C# Code
   
   [Beta]//will not be deployed
   public void NewFeature() { ... }
   
   BUT: what about features, that require a database schema update? I don't want to deploy volatile schemas!

   Reply

3. Back to top

   Learn from the game developing community

   by Zhu Jia Cheng

   My little experience in the game industry tells me that every functions would(should) be programmed configurably for a large project, as programmers' work get feedback from/cooperate with art/design team instantly, and get new features and requirement during very short time. Before that I only had ideas of IOC from Spring.
   
   So I wish to hear/see from game developers.

   Reply

• Older >