On deployment and enviromental risk

One hot topic that you often get when you have project teams delivering functionality for user acceptance testing while support are testing ad hoc fixes for production issues is "Who owns the environment and how do we stop support and project work from interfering with each other?".

I feel that all code changes and deployments to customer facing sites should have some kind of change management paperwork raised. Because of this you are able to catch scheduling/work conflicts in the change advisory board. A good change control process should help you think about the risk to your project and also help flag to other stakeholders that they might have a risk to consider.

A very basic rule of thumb for deploying anything to production in a manually controlled environment is don't expect that no other changes to have been made since you took your base to work on and always check before merging in. Here I think a "manually controlled environment" is somewhere that developers and application support have write access directly to production and UAT servers and that deployment is typically done manually by a developer or application support developer copying files and installing etc.

In this environment I would consider it a project risk that any UAT sites have the potential to have emergency support changes made and/or in test. A Few things that I would do to help mitigate this in the short term:

•    Use the CAB process as fully as possible, this makes everyone aware of what you intend to change and when 
•    Confirming with support before proceeding and referencing the CAB form – do you need to do anything? Is there any reason we shouldn’t proceed?
•    Check what is there as you deploy – is it what was there before we started development? Have any CABs been raised for these clients/environments that might impact our project?

This is assuming that any inter-project team conflicts over environments can be resolved in regular PM/programme management meetings - I would place the onus on the project work as I would have thought that project deployments should be able to be planned far enough in advance to do this. IMHO it is typically a lot easier for project teams to check and plan for this than it is for support given the nature of the work.

In the longer term it makes sense to migrate those clients to an auto-deployment structure from a "source of truth", for which I would strong recommend a good source control system. Then place stricter controls on environment access at the server level. Ideally I wouldn't want anyone other than operations staff performing anything other than infrastructure tasks directly on the server. For things like logging there are enough ways of piping logs off and examining Windows event logs remotely that developers and application support shouldn't need much - if any - server access.

On documentation and organisational knowledge

It's been a while since I've written up a work orientated blog post. At the moment two (relatively ;) exciting things are happening. One is the introduction of JIRA, Confluence and GreenHopper and the other is working on a series of projects to upgrade customers, getting them onto the latest version of our company's main product. I'm working along the lines of getting three categories of info in JIRA/confluence:

1.       Jira work items

2.       Confluence (upgrade) project wiki

3.       Confluence wiki page per customer

The first item should be quite straight forward and contains information needed for the life time of that work and a point in time record of the system (i.e. what was the state of play when the JIRA was raised/worked on?). For example, a story on a feature has the handover documentation for the original implementation attached as word files, so the current state of play now is easily accessible. I've also then created a subtask to update a linked version of this held in the wiki (the word document content as a wiki page, to do this I've used the standard "Import Word Document" function to upload the handover documents).

The upgrade project wiki holds the "project headlines" of the project, e.g. quick overview of the client and how they will benefit from the upgrade, and any analysis that comes up out of it. This is a record and audit trail of the project (at a higher level than any JIRAs above). This is a natural extension of the project headlines that we had been producing as Word documents moved into JIRAworld.

Finally under the main product project a single page exists per customer and then sub-pages under that per piece of functionality/project. This should document the live version of the customer's system as it is now. This is currently less than ideal, for example looking at one piece of functionality for a client. I've imported the handover documents as they were delivered by project to support, and as you might expect each project only details the work they have done - so you need to read and understand all three links to get the overall picture. Hopefully the upgrade projects will smooth over some of this and detail the whole functionality as upgraded. But this may also require a slight culture change with on-going projects and their PMs to encourage and guide their teams to update the documentation (and not just add their own bit as a new page). This is the new bit where we can add value to what we already do, with very little extra effort.

As you can see the three layers build up in order of longevity and should give oversight about what was done, by whom and when. Also being a wiki we can go back in time and have a look at the page histories to see what the state of play was at any time this can be useful for comparing what a project changed at a high level, by looking at the versions of the customer page before the started and after the work caused the page to be updated (if that makes sense?)

Oh, one more thing I am trying to work on is getting pages that contain guides to some customer specific logic to be aware of and also the projects that either didn't get signed off or aren't quite in the core product yet (added with a warning as reference).

Once pages are in Confluence they can be moved around, so putting them in there isn't wasted effort as and none of this pre-supposes wherever the company decides where our source of truth is, each Confluence page has "Export to Word" and "Export to PDF" options, so we can take versions and save them wherever our hearts desire ... a network drive, Zendesk, Sharepoint, MySpace, Yammer, Salesforce .... the list goes on (as do I ;). This is one of the reasons I’ve pushed on getting it all in Confluence now, I know that I can export updated documentation as required at the end of each upgrade project and that it will be in a similar format to what we have now (if that's required).

Further Reading

One thing that is important is having a common language used by all the company's employees. The next step would be to also build up a glossary within the same wiki framework. OpenBet's approach to knowledge management uses a third party plugin to extend the basic Confluence pages, read about on the Atlassian blog here and part two here