Release Management

Why You Need Tableaux

Why You Need Tableaux

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.

Heroics

Do you rely on continual heroics from a few individuals (who will eventually leave)?

Individuals like heroics because it makes them look like heroes. However heroics are problematic for your organisation because usually it means:

  • Extra overtime costs
  • Uncertainty of project delivery
  • Inability to reproduce actions
  • Staff fatigue
  • Tightly held or closely guarded knowledge

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:

  • Certainty in project deliverables, budgets, timetables.
  • Reproduce a deployment perfectly.
  • Instill a culture where bugs and deployment issues are picked up earlier, making them cheaper to fix.
Developers

Do your developers deploy directly to production?

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:

  • When let loose in production, developers often do not adequately pass deployment instructions to infrastructure staff.
  • Some developers are disciplined and fix the root cause of problems. Many are not. Without fixing the root cause of a problem, future deployments will suffer the same problems.
  • The state of your environments may differ, requiring "hacking" in production
  • Developers know production passwords - this is dangerous because developers are interested in getting their application running, with traditionally little regard to the security and integrity of production systems as a whole.
  • No audit trail of actions are kept.
  • Infrastructure staff have no control over production environments.
  • Since the state of the environment is unknown, it is difficult to attribute any bugs in the code back to a known version of the application.
  • You have to change your production passwords each time your developers leave/move to other projects.

Tableaux is the medium between developers and infrastructure. Tableaux captures developer knowledge and allows infrastructure staff to "re-play" their knowledge into production.

Benefits:

  • Knowledge is captured and stored in the system. Ramp-up time for new staff is reduced.
  • There is no "hacking" done in production
  • The state of the production environment is known and reproducible.
  • Departing staff pose no risk because they are not taking with them exclusive knowledge of the application, nor the production passwords.
  • Lessons learned are captured and learned from... not hidden and remain an overhead for the next deployment

Manual deployment instructions

Do your developers hand over pages and pages of deployment instructions?

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:

  • Software releases are faster. Tableaux can compress deployment times significantly for a number of reasons.
  • Tableaux produces your implementation plans, typically saving release management team weeks of work.
  • For releases that require steps to be undertaken by multiple groups (eg, Identity management group, DBAs, Midrange and desktop teams), Tableaux saves the dead "task switching" time.
  • Releases become "re-usable". You can use a past similar release as a template for a new release. This saves large amounts of time.
  • Tableaux produces accurate release time estimates (based on its past experience).
  • Releases become more accurate, which means increased uptime and stability for your bespoke IT systems.
Friction

Is there friction and distrust between your development, infrastructure, CM and DBA teams?

Most organisations suffer from a poor relationship between developers and infrastructure staff. This is often due to many factors.

  • Developers want more access to production
  • Infrastructure staff want to lock environments down
  • Infra are continuously disappointed by perceived low quality in deployment deliverables.
  • Infrastructure staff get blamed when a new application fails in production, even though it may be badly coded.
  • Database Administrators trust no-one, and run everything in dev, test and production by hand.

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:

  • The mechanism for the deployment has been coded by Infrastructure staff (they can write the plugins). Thus the deployment occurs exactly as Infrastructure design it.
  • Deployments are audited.
  • Deployments require electronic approvals in more critical environments, so no developer can circumvent the system.
  • Usual CM policy dictates that a deployment must go through dev and test environments before production. Infrastructure staff have confidence in the production deployment because it's been deployed identically into previous environments.

Benefits:

  • Tableaux bridges the trust divide and helps drive cultural change. Trust between Infra, developers, DBAs and CM will improve.
  • Teams work more efficiently when all staff are on the same page.
Large releases

Do you have large, infrequent releases because making changes in production is difficult?

Many organisations suffer from a deployment feedback loop:

  • As releases grow larger, you spend exponentially more time managing the components of the release. You end up releasing only every 3 months because the releases are too large and complex to deploy any faster. Ie, releases become exponentially larger as they become more infrequent.
  • Releases become more infrequent as they grow larger.

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:

  • Increased confidence in the software development release cycle helps drive political change for more frequent releases.
  • More accurate software releases increases the stability and uptime of bespoke systems.
  • A monthly or weekly release cycle brings patches and enhancements to the Business sooner.
  • Quicker return on your development investment.
  • Beat competitors to market by delivering your products sooner.
Heroics

Do you play the "blame game" after large releases to production?

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:

  • Problem diagnosis becomes a mature investigation, rather than a witch hunt or "blame game".
  • Less time is taken pointing fingers. More time can be invested in resolving problems, whether they be in the code or in the infrastructure.