I'm interested in how other people have handled this.
We have multiple teams. Each team works on a (somewhat - see later) separate solution, and produces new releases at the end of every Sprint, in theory, but multiple releases anyway.
All the releases are deployed onto the same shared infrastucture. Multiple (hardware) servers run a number of server (software) applications, and the solutions use one or more of the applications, extending or customising them as required. Solutions normally share the same schemas for the database as these are part of the application servers.
Some of those extensions/customisations can (or should be, to avoid multiple changes and fixes) shared between solutions.
There are several environments - Dev, test, staging and live/production. Deployments to environments other than test are under change controll, but are made by each project on their own schedule
So we have multiple levels of sharing. If one project wants to use a later version of a shared server app, or change a shared customisation, then there's a risk that the other projects won't work with it without changes, or at least won't know this without testing.
Our first issue is on the single Dev environment. We'd like to keep things fairly agile, so we don't want all changes to the shared parts to have to be agreed and scheduled before they can be made. But we don't want one project
On the others, we're not sure how best to handle the need for other projects to test/update to be compatible with changes a specific project wants to make to shared things.
How have other people handled this problem of multiple projects sharing infrastructure?
Current thinking (not really thought through yet(
Create a DEV environment per project.
Define a baseline configuration for the shared components. For a sprint (or maybe several sprints) a particular project works starting with the current baseline configuration. Their changes may include updates to that baseline.
Eventually, all the baseline changes need to be integrated and a new baseline configuration defined. We might do this once a month (so there's a sort of infrastructure project that also has Sprints). At some point (it's a bit fuzzy here). a project must update its DEV environment to the revised baseline.
The baseline configuration of environments other than DEV is changed on a regular schedule, following the release of a new baseline version. Project releases to envs other than DEV must work with the current baseline configuration version for that environment, and ideally would be released along with the updated baseline configuration. If they don't release before the baseline is updated again and haven't caught up with that baseline, they cannot deploy, they'll need to update and re-release.
To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe <at> eGroups.com