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?

Improve this question
1
  • If there is a missing stage because your environment has an extra integration layer, then feel free to add it: that's agile!
    – Erik Eidt
    Commented Oct 7, 2020 at 16:21

1 Answer 1

Reset to default
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

Improve this answer
11
  • "An Agile approach would be [..] teams wouldn't own a single step in the chain, all teams would add features to all steps." This is a matter of scope and size of teams. For a rather large corporation, it's not going to be trivial for any developer to have to manage the entire process from beginning to end. There's room here for specific teams working on specific applications, but using an agile mindset and coordinating with each other. The dependent services can always go live before the services that depend on them if you account for breaking changes using versioning.
    – Flater
    Commented Oct 8, 2020 at 15:19
  • I disagree. I'm not saying its the only agile approach, but i think the key thing in agile is having a team deliver a feature end to end. As soon as you have to schedule work with another team the process starts to break down. You have to learn to trust developers to work on all the code, not just a small part of it
    – Ewan
    Commented Oct 8, 2020 at 15:31
  • For microservices in the context of one or more client-facing applications, I agree. But scope is really important here. I've worked for a massive multinational (one of the brands everyone knows across the world) and in no way would our team (handling the warehouse packaging software for a specific region) have been allowed to freely rewrite parts of the global identity server and its authorization logic as we saw fit. There are reasonable boundaries to draw.
    – Flater
    Commented Oct 8, 2020 at 19:09
  • well, ditto, and its a problem. If the auth guys need to write a spec for the warehouse guys and get it scheduled in and completed before they can complete some new feature then that's waterfall and it causes project failure. The fact that company X hasn't been able to achieve vertical slices, or that developers get comfy with 'their' apps doesn't make it good practice
    – Ewan
    Commented Oct 8, 2020 at 19:29
  • Thanks for your answer, but what you say is that my whole company or at least my SAFe project (100s of dev) should change its structure (that's not happening :) Also, I understand and would like to agree with you, but I think there are cases like mine where it is not possible to split the work the way you say. All main non-reducible business features couldn't be setup by a single team in less than one of two years. So we need methods to cope with that.
    – Juh_
    Commented Oct 9, 2020 at 8:52

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.