Many see Configuration Management as a hindrance to a software project. But effective CM can actually be your saviour. The following scenarios are all examples of poor CM that can be addressed and removed by Tableaux.
Individuals like heroics because it makes them look like heroes. However heroics are problematic for your organisation because usually it means:
Heroics are a symptom of poor Configuration Management. Heroics are required because your product does not work the same in testing as it does in production.
Tableaux reduces heroics because it deploys your entire release identically in every environment .
Benefits:
Nobody knows the product best like the developers. When there's a problem during or after deployment to production, you give the developers direct access to production. Or even worse: you let developers perform the deployment.
There are several problems here:
Tableaux is the medium between developers and infrastructure. Tableaux captures developer knowledge and allows infrastructure staff to "re-play" their knowledge into production.
Benefits:
As your software releases become larger and your systems become more complex, the deployment instructions likewise grow in both size and complexity. It is not uncommon for a project to hand scores of pages of deployment instructions from developers to the release management team (or Infrastructure).
The likelihood of manual mistakes increases exponentially with the complexity of the instructions. There have been numerous large-scale and very public production failures due to manual mistakes made during production deployment.
Tableaux's release management capabilities captures every step of a bespoke software release. You can even include manual tasks in the release kit, either permanently or as a place-holder till the task can be automated.
Benefits:
Most organisations suffer from a poor relationship between developers and infrastructure staff. This is often due to many factors.
Tableaux becomes the formal "meeting place" between developers and infrastructure staff. Tableaux provides a framework for Infrastructure to set deployment "boundaries". Developers work within those boundaries.
Tableaux becomes a self-service mechanism for developers. Infrastructure staff are happy for developers to initiate deployments because:
Benefits:
Many organisations suffer from a deployment feedback loop:
It is dificult to break out of this cycle due to both political and technical reasons. This isn't entirely a problem that employing a new development methodolgy (ie, Agile) can fix.
The release cycle is as much driven by Business requirements and confidence in the IT department, as by the skill of the IT staff or the size of the release. Once Business confidence in IT departments is lowered due to several problematic releases, it is often difficult to negotiate for faster releases.
Tableaux reduces the effort required to manage large releases. Large releases become easier and quicker to deploy. This can help facilitate more frequent releases.
Benefits:
A healthy deployment process always includes a post-implementation review process. With poor configuration management practices, and a low software development maturity level, this review process becomes a witch hunt.
When a project release fails (and according to the Standish Group's Chaos Report, only 9% of projects in large companies are successful), it is our experience that Infrastructure is usually blamed first.
Witch hunts benefit nobody. They sap time, reduce moral, and instill a Cover-Your-Ass culture.
Using Tableaux to manage your software development process allows you to pinpoint where problems occur. The blame game disappears, the problem is found and fixed. Lessons are learned. The issue is captured in the release kit.
Benefits: