4

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.

3

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.

  • Hello Bill, appreciate your suggestion on how to structure the environments, and actually you nailed most of what we have (including a PROD-like environment for comparison / check purposes). The underlying question, however, is not answered: how to ventilate the environment usage today in in a month from now? In a big white drawboard with lots of post-its on it, using colors for stages, rows for clients and columns for dates? That's what I'm planning to do... – Tiago Cardoso Jun 19 '14 at 1:29
  • Try to keep as many environments dedicated. (It will take a bit of work to migrate releases into them.) If you can, rotate the release date environments in a predicable manner. With monthly releases and three environments - A: Jan, Apr, Jul, Oct; B: Feb, May, Aug, Nov; C: Mar, Jun, Sep, Dec. – BillThor Jun 19 '14 at 3:17
  • Hi! Just expanded the problem, adding 'in a fluid environment where priorities are constantly changing'... i.e. having a closed plan (which would be great) is not realistic – Tiago Cardoso Jun 19 '14 at 10:24
  • 1
    @TiagoCardoso An overly fluid environment test towards lots of things gets started nothing gets finished. Worst case I was involved in we implemented the same functionality three times the same week, and removed it twice. I can't remember if we left it in (four days wasted effort for one days progress) or took it out (six days wasted effort). The developer on that project was eighteen months into a six month project. If you can't resolve the fluidity, it may not matter where you test it. – BillThor Jun 19 '14 at 22:42
  • Completely agree, I've been through a similar issue this week. Nevertheless, we have to keep up trying to improve what we have... and here we are discussing the problem :) – Tiago Cardoso Jun 19 '14 at 23:13
3

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.

  • We do have a release and environment manager, but it's very hard to keep up to date on the details of so many changes with so many people working on the same 'project'. Also, having less environments would mean we wouldn't be able to deliver as much as we could due to environment restrictions (i.e. environment would be a bottleneck that could be easily overcome adding money)... so not an option either. Besides, the main problem is still open: how to present / expose the current environment usage to all the team? Is there a calendar-based view in Sharepoint? Tks! – Tiago Cardoso Jul 1 '14 at 16:06
  • At my company, the Sharpoint site provides what is called a Calendar and an Event Calendar. Perhaps you could use the Event Calendar as a way for everyone to see important action dates. Example, "Test envrionment TEST1 will be refreshed with prod data beginning at 7:00 AM EDT". – Philip Kolocotronis Sep 15 '14 at 14:50
2

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.
  • Effectively a work authorization system? – Mark C. Wallace Jun 25 '14 at 12:27
  • I really like the concept of application version instead of artifacts! Still, the underlying question is opened... what kind of shared document would fit this need? – Tiago Cardoso Jul 1 '14 at 16:08

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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