Comments on Better Projects: Deployment Gone Wrong

The only consistent solutions are to integrate oft...

2008-04-15T04:22:00.000+10:00

The only consistent solutions are to integrate often, automate deployment, and have automated integration tests that run whenever changes are made. In my experience, these things cannot be driven from outside of the team.

@Andrew, I have experience with an Agile project with many releases over time. Configuration management has not been a particular problem - we have the minimum lightweight process we need in order to manage it. We have improved over time, responding to problems and building on our knowledge and experiences.

it saddens me that your focus seems to be from ...

2008-04-14T13:21:00.000+10:00
it saddens me that your focus seems to be from necessity in micro-managing the IT team in doing the job they are meant to be doing themselves as a means of risk mitigation, and in doing so overlooking the BA's role in configuration management,

Believe me Andrew, it saddens me just as much as it saddens you. In my opinion, these people shouldn't need to be micro-managed at this level. In fact, if I could get management support, I would have had this process issue addressed.

I am hoping that the CMMI level 3 assessment we are being forced into will solve the problem. Unfortunately that is at least a year (and several product release cycles for multiple products) away.

I think that most BAs will try to address this from a process perspective. That's why I focus on the idea that one must accept that sometimes this issue will have to be addressed from a risk mitigation perspective.

Janet

The level of a teams maturity can be measured in t...

2008-04-14T11:51:00.000+10:00
The level of a teams maturity can be measured in their approach to configuration management :-)

From my personal experience, the one area most often overlooked by all parties, and also not mentioned here is the treatment of in-flight data, particularly in workflow systems. That is data that is currently being processed in some manner and is in an indeterminate state when the migration occurs.

The other often overlooked area is impact to existing data. A new field is added and existing records all get the new default value, but often that default value does not make sense for all stages of the lifecycle.

This is where the value of a good BA comes to the fore. Being able to work through the implications of a change on existing data and work with the technical team to cater for the identified impacts. Sadly, it has been my experience that this task is usually left to the technical team to take care of with mixed results.

The topic is a huge one and it is great that you bring it up. However, it saddens me that your focus seems to be from necessity in micro-managing the IT team in doing the job they are meant to be doing themselves as a means of risk mitigation, and in doing so overlooking the BA's role in configuration management, which in my mind should primarily be analysis of the impact from the change, and the corresponding verification of the success of that change.

I have worked in many traditional process orientated teams and configuration management plays a big part in the teams process. Even then, configuration management can be a difficult beast to keep tamed.

I have also worked in a few Agile green fields projects, where everything was new and ongoing migrations where not such a big deal as we were only responsible for the initial drops into Production. It would be interesting to know what experience other people have had with Agile projects on mature systems and whether configuration management on such teams is problematic.

we feel your pain

2008-04-14T10:56:00.000+10:00
we feel your pain