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
  • 6
  • 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 Oct 07 '20 at 16:21

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
  • 70,664
  • 5
  • 76
  • 161
  • _"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 Oct 08 '20 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 Oct 08 '20 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 Oct 08 '20 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 Oct 08 '20 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_ Oct 09 '20 at 08:52
  • I understand your argument, though: The way it have should been. But I my-self don't see how they could have respected that rule. – Juh_ Oct 09 '20 at 09:01
  • well not every problem has an pure tech answer, But I are you not able to at least submit PRs for the dependencies? the other teams then just have to approve and release – Ewan Oct 09 '20 at 12:47
  • That should be ok other team usually appreciate that we to their work :) But I can't do all the work. Also, to be clear, I am dependent of their application and outputed data, not directly their code. For now, every team deploy their app the way they want (before prod). So we connect to which ever deployed environment each team decide. Their is no organisation. And once reaching prod, we can just hope that everything will be properly connected after deployment. – Juh_ Oct 09 '20 at 16:31
  • the test env is a separate problem in my mind. If you have "mutiversioned" env then you can choose which version of the dependency you connect to, which make it easier to create new versions because you only risk breaking your stuff. But eventually you (or some other team) have to regression test the new version otherwise you end up splitting the codebase – Ewan Oct 09 '20 at 18:19
  • i would avoid from experience : 1. test env for every feature branch/version (expensive/complex) 2. single test env with vnext (slow to release) – Ewan Oct 09 '20 at 18:22
  • if you cant have multi version you could try scheduled releases, in this paradime you get a bundle of tested features on a known date. It adds... sanity...# but its v waterfall and you have to wait if your requirements have changed – Ewan Oct 09 '20 at 18:24