-2

We are a central team, responsible for around 10 services. Other parts of our company depend on these 10 services to write their applications, and we often have to collaborate on new features before they're ready for production.

I'm wondering how to accomplish CD with this sort of situation. I'm sure it's been explained somewhere, I just haven't found it. Currently our process is:

[production]
     |
  [stable] <--> {internal partner}
     |
   [dev]

My concern with CD is how do we coordinate new features that aren't necessarily ready for production with our internal partners who depend on those features to finish their integration?

An Example:

We want our online environment to support awesome_matchmaking_feature_xyz for our gameteam. The gameteam wants to start development on their game using this awesome_matchmaking_feature_xyz. We need a way to provide that feature to them, but it's not considered "releasable" work yet. Additionally, we have 7 other awesome_x_feature projects that need to be integrated against by different gameteams (or even different groups within the same gameteam).

In my mind, the only way to accomplish this is to have a dedicated environment for this feature, separate from the main dev-stable-prod streams. But what happens when we have 7 of these initiatives going on at once? Do we spin up 7 dedicated environments for each test? That could get expensive pretty quickly. What happens when these features are ready to be merged into our primary streams, and the other feature development doesn't have them yet because they're working on their feature streams? I'm curious what the proposed CD best practice for this sort of thing is.

ctote
  • 173
  • You do understand that once you go on non-ephemeral feature/development branches you're pretty much saying bye-bye to CD, right? – Dan Cornilescu Mar 17 '19 at 05:30

1 Answers1

2

the only way to accomplish this is to have a dedicated environment for this feature

Unfortunately yes. And then as you note, you end up with millions of environments. Not an impossible thing to deal with in these days of cloud deployments though. And in my experience spinning up more test/QA/dev environments to order is the most common approach.

Alternative approaches I have seen:

  • Very clear specs and a waterfall style approach, where you complete to spec, release and move on.

    You can improve on this by having the requesting team implement a mock service to the interface. Enabling them to develop their stuff while you work on creating the real version. But you inevitably end up releasing something that needs changes later.

  • Feature flags. These enable you to release the feature without having it 'on'.

    In theory. Personally I find this a bad solution. The code gets released and you just trust that it doesn't introduce bugs because of your feature flag code. Then you get a multitude of tests for combinations of feature flags.

If you can get the "we agree on the interface spec" approach working, then it's by far the best. But I would fall back to the multiple environment approach where this cannot be achieved.

Ewan
  • 75,506
  • Unfortunately, waterfall approach isn't something we'd be interested in. We're pretty ingrained in an agile development process at this point; I'd like to catch our deployments up to match that rather than reverting our development to accompany our deployment process. Now I'm wondering how to manage the cost of all of those ephemeral environments. – ctote Mar 15 '19 at 17:14
  • well if your in the cloud and its low volume dev stuff you can get away with free tier and/or turning them off at night – Ewan Mar 15 '19 at 17:36