0

I am looking how agile methods can be applied for setting up a chained-application (made of several services for example) developed by several teams. In particular, I think the common sources about release-cycle and environment layers (DEV, UAT, PROD) are missing a step where all applications should start to connect with each other.

This level could be called integration-testing, but this concept is used at a lot of levels so it would be confusing: in IoC (Spring) it simply means to connect all software modules/beans of one application together ; in the CI world, this is a place where one team automatically tests its components with respect to normalized/prepared input, that should change only if it is a business or technical requirement that has been validated.

It is missing a cycle step and associated environment where all applications (and data) evolve continuously like in prod, but can and should communicate with each other. This is also the environment that other teams will connect to while developing (in their dev env).

While several team I work with would dedicate one DEV env for that purpose (usually where CD is used), I think this isn't the right choice because by definition DEV env are freely breakable and deployed version are not (necessary) labeled. I consider this should be done in the UAT environment, on a release or some tagged software version such as a pre-release. Why UAT? because once all parts of the chain are provided (maybe with mock), the users can access it, test it, and provide feedbacks. But maybe I am missing something, and when discussing with my colleagues, not everyone understand me or even agree with me if it doesn't fit there method.

=> So how agile method answer that issue, and is there good sources that discuss about this?

Juh_
  • 171

1 Answers1

2

The problem with a "chain" of dependencies with each developed by a separate team is that it is inherently waterfall.

The classic way to deal with it is to have each component declare its interface in advance of development so that other teams can develop to the interface and then test against that interface.

This allows each team to work independently, but fails because its next to impossible to define the interface that will be needed on day 30 on day1

An Agile approach would be to have teams work on vertical features rather than horizontal components. So teams wouldn't own a single step in the chain, all teams would add features to all steps.

In terms of testing I think any dependency chain requires multiple versions of the steps to exist at the same time. ie TeamA might use v2 of some dependency while at the same time TeamB is using v1

This enables updates without a cascade of revision testing and blockers where unrelated features need to be updated before a new feature can be launched.

It also means you can have a single UAT env which matches live (or vNext), rather than multiple environments all with different features and versions of dependencies

Ewan
  • 83,178