BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage News Enabling the Last Responsible Moment in Deployment

Enabling the Last Responsible Moment in Deployment

This item in japanese

Bookmarks

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.

 

Rate this Article

Adoption
Style

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Community comments

  • How about run-time permission-based controls?

    by Cornelius Perkins,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    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.

  • hard to implement

    by Andreas Kleffel,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    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!

  • Learn from the game developing community

    by Zhu Jia Cheng,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    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.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

BT