3

In our IT dept we develop multiple systems in parallel, the systems are deployed to different environments, and they talk to each other using SOAP and REST. It's all ASP.NET but we're not in the cloud. I'm trying to find a way of streamlining environments to reduce complexity.

Simplified view, let's say there are 3 systems in production: A,B,C. They communicate like this:

  • Prod: A 1.0 => B 1.0 => C 1.0

We mirror that in a test environment like this:

  • Test: A 1.0 => B 1.0 => C 1.0

If there's an urgent production bug in B, we would make a fix to B and deploy it to the test environment.

  • Test: A 1.0 => B 1.1 => C 1.0

and if integration tests pass we can release it to production:

  • Prod: A 1.0 => B 1.1 => C 1.0

Now let's say we develop a new feature which means A and B both need to change. Both A and B are being deployed to test.

  • Test: A 2.0 => B 2.0 => C 1.0

During this development period, if an urgent production bug is found in B, we would have to make a fix to B and deploy it to test environment:

  • Test: A 2.0 => B 1.2 => C 1.0

Obviously this is shaky ground now because the test environment does not resemble production. And what about when B 2.0 has a breaking change - in this case the A 2.0 will fail when pointing to B 1.2.

So what we've done is create another environment for emergency fixes, called Patch. So we can have:

  • Test: A 2.0 => B 2.0 => C 1.0
  • Patch: A 1.0 => B 1.2 => C 1.0

Now A, B and C each have different delivery cycles, so what tends to happen is that at different stages of the project, the Patch environment is abused in order to test different versions of each component for the current release or for the next release. We end up doing crazy stuff like pointing Test A to Patch B, or pointing Patch B to Test C. And this obviously generates huge confusion. Not to mention that this is a massively simplified version, in reality we have at least 8 systems involved here, with 6 environments. The TeamCity summary page is like spaghetti junction. Also some environments talk to each other (in my example above it would be like A => B => C => A).

Please help me understand how this type of scenario can work.

demoncodemonkey
  • 169
  • 1
  • 5
  • 2
    Are you using a source control system? Which one? Generally your *branching strategy* would solve these kinds of problems. For an example in Git, see http://nvie.com/posts/a-successful-git-branching-model/ – Robert Harvey May 27 '17 at 20:51
  • We use TFS for source control. We work in trunk, then a few days before a release is due we cut a branch so it can be tested independently of trunk changes. Any changes made in the branch are merged back into trunk. – demoncodemonkey May 30 '17 at 10:39
  • 2
    Consider using feature branches. See [here](https://www.visualstudio.com/en-us/articles/branching-strategies-with-tfvc) for more information. – Robert Harvey May 30 '17 at 21:25

0 Answers0