On an IT project, how to manage and publicize (development and testing) environment usages?

Question

Question: How to broadcast to the whole IT team the current and future environment usage plan, in a fluid project with constant changing priorities?

Background:

When a project is relatively small (5 to 10 people working with a specific module and with a dozen artifacts), the development cycle is relatively controlled: All stakeholders are aware of what's the status of testing in progress in each (physical) environment. It is possible to

• build local ->
• promote into testing environment for integration testing ->
• promote for user acceptance ->
• promote into PROD.

That's bread and butter. There's no need to track 'environment usage' because it's natural.

However, on bigger projects, having a controlled environment usage is a must to avoid overlaps and clashes. Assume the following scenario:

• 100+ developers and analysts
• 10 Internal testing environments
• 4 User testing environments
• 6 project 'components' (a.k.a. sub-projects with specific team leads)
• 9 clients (the project is 80% shared between clients, with a few specificities)
• 50+ artefacts
• 3 branches per artefact (development / testing / pre-production)

Taking into account each 'sub-project' can be touching several artefacts at once for different project phases and clients, planning and controlling such environment usage is a terrible pain.

Is there any methodology or best practice recommended for or related to control and communicate environment usage?

Is there any default view to present this to all stakeholders? Having one Excel sheet with a calendar with all the above aspects, as one might deduce, is terribly complex and hard to read for a new joiner.

Consider a physical environment as one resource, per se, doesn't address the question, since you can be operating with 1 or 9 clients at once over the same resource, as long as the development phase is the same. Likewise, you cannot have in the same environment two clients working on different development phases - as the maturity and requirements are different at each stage.

Answer 1

You should designate someone on the IT team, probably a System Administrator, as coordinator of the various environments. They should be able to coordinate and control when environments are refreshed, when code packages are migrated from one environment to the next, and what the schedule is for vendor-supplied patches and updates (if applicable).

Best practices say to have as few environments as possible. When you have too many , keeping them up to date with vendor upgrades and production refreshes becomes very difficult. When using vendor-supplied software, always keep one as a “vanilla” environment that contains the software as delivered off the shelf. Another must-have is a “hot backup” of production, probably refreshed daily or even multiple times per day. This is practically a must to debug production issues.

Your Sys Admin should meet with the developers and testers to come up with an agreed-upon migration schedule. It is also a good idea to have a standard way for developers to document what is in a particular code release. As far as communicating this with the project team, I think a calendar-based tool – such as in Sharepoint – provides a quick and easy way to see the upcoming code migration and patching schedules. If more detailed information is needed, that can be tracked in a spreadsheet or similar way. Sys Admins and DBAs in particular might need the more detailed information.

Answer 2

Scaling out brings a lot of overhead. There will be more of everything to co-ordinate. Try to have as few test environments as you can. This will simplify the co-ordination. It will also force your developers to deal with the integration issues up front rather than once they have completed development. Good development practices should reduce the integration issues, but some will still occur.

You likely want a testing environment containing production code, and possibly one with the prior release. This eases determining if a bug is new or existing.

Add some testing environments for the next X releases. Keep X low. Once an testing environment is assigned to a release keep that release there. This will simplify tracking which release is where. You may want environments for development and testing for each release.

Pre-production branches / release candidates would be assigned to a user testing environment. You may want production and the next 2 or 3 releases. Rotate the release environments so only one is changing at a time.

If there is any integration between the artifacts, it helps to have all projects integrating into the same environment. This should make integration issues visible at the earliest possible time.

Keep all the clients in the same environment if their release date is the same. Making changes to the same code for multiple clients will require some co-ordination. It may also require some negotiation of conflicting requirements. This should be dealt with as soon as possible.

It is a good idea to have automated regression tests which can be run in each environment. These should test functionality, not look and feel. My experience with commercial tools is they make the look and feel easy, but not the functionality.

Answer 3

From my point of view and being very pragmatic:

• Required a release and enviroment manager.
• He/she will coordinate the releases and will have an updated picture of the usage of each environment. In a shared document.
• This manager will establish a rigid policy for deploy/env. usage, at least until all teams are conformatable with the new procedure in place.
• Use the concept of application version instead of artifacts. I do not see any benefit to work with artifacts separatelly. The deploy procedure should work at application level and if a promote is required, then all artifacts should promoted under a unique application version (but with different artifact version). This will simplify a lot the process.
• To help to the above process, the packaging and deploy process should be optimized as much as possible.