How to update all environments after production deployments

We have several teams that work on the same components. Each team has their own branch of code and servers for Dev and QA. They all check into main to go to prod. What are some strategies to keep each teams dev and qa up to date with what is in production to test against production like environments?

Scenario: Team A is working on Component A
Team B is working on Component B and B depends on A
Team A promotes a new version of Component A to prod. How do I get the new version of Component A on Team B server so they start testing against it for their new changes of Component B.

Hi Jeremy,

Thanks for getting in touch!

How are you sharing your components ? Are you using an internal Nuget feed?

Regards

Damian

Yes

Jeremy Hillin

Hi Jeremy,

Typically a new version of a component would mean a new build, a new set of unit tests then a new release in Octopus. Perhaps you could have a regular / nightly build process that pulls latest of everything ?

Regards

Damian

I don’t think you understand my question

Jeremy Hillin

I never got a response to this? I am trying to find out ways to update all
lower environments, for other teams, after an app is deployed to
production.

Sorry Jeremy

I missed this.

You are correct, I don’t really understand your question. I see a component as a shared library or similar which I’d share with a package repository. Obviously this isn’t how you see things, perhaps you can explain your workflow and app structure more deeply ?

In any case though, we don’t have an out of the box way to do this (yet). You could look at creating a script step which called back into the API and triggered a new release or deployment based on the success of another ?

Damian

Here is an example. Team A devlops windows service that team B uses. Team
B has a multi month develpment project going on. Team A release 3
versions of the webservice during that time. Is there a pattern where
after every release of the windows service Team B dev and qa environment
are automatically updated with the windows service so that Team B is
testing aginst the latest version.

Hi Jeremy

Thanks for the explanation. The term component was where I misunderstood.

So no, it’s not something we’ve built. If you wanted it in Octopus I’d either have a powershell step that triggered a new deployment into the QA environments based on a successful production deployment using the API. Or you could do an email step based on a prod deploy that notified the other teams so they could pull it into their environments when it was convenient.

Regards

Damian