techmaturity/techmaturity: the maturity scoreboard Ticketmaster open-sourced

It was an internal tool before it was a public one

The title carries its own history: the project is named Techmaturity and the heading notes it was previously Ticketmaster Tech maturity. The README is still written in the first person plural about an internal programme, describing what the model helps the authors do for their own organisation and then, at the end, saying they are excited by the community response and thrilled to share the tool with others. Two links support that framing, one a video and one an internal engineering blog post on the company's own domain. The consequence for an outside reader is that the model arrives with its original use case intact rather than rewritten for a general audience, and the recorded primary language for the repository is HTML rather than Ruby because the graded artefact is the web interface, not the Rails code behind it.

Five dimensions and no prescribed solution

The model is described as a path that can be completed in stages, with flexibility in how you move through five key dimensions of software development: Code, Build and Test, Release, Operate, and Optimize. The framing is deliberately non-prescriptive. Rather than telling teams what to do, it offers standards, with the stated aim of giving teams a clear path towards efficient product development at scale, and the claim is that it can be tailored to specific needs. The evidence offered for that claim is range: the authors say they applied the model to products ranging from VAX code to JavaScript libraries, because their technology estate spans the 1970s to the present. So the scoring surface is reusable across very old and very new code, while the criteria underneath it are yours to define.

Cloud readiness was the first concrete job

The clearest description of what the model was built for is a migration. For the authors' move to the public cloud, it served as a cloud readiness gauge quantifying how close a product was to being ready for migration. The method is stated plainly: targets were established for a subset of capabilities believed to define the minimum requirements for any product or service in the public cloud. That gives teams owning legacy products something they can track, and it also let the company operate in a decentralised, self-service way, so a team could run its own migration without waiting on a central group. This is the part worth stealing even if you never deploy the portal, because the score only exists to make a large migration visible to the people doing the work.

A portal exists because a scoreboard needs an audience

The reason there is a web application at all is given in one line: you cannot tell whether you are winning without a scoreboard. So a portal was created to gather, aggregate and display patterns from the assembled data, and to make it visible to everyone in the company. Strategically it is described as a key indicator of performance, so that value-driven improvements can be made continually rather than annually. The release history is thin but points the same way: a single version, 2.0.0, whose release note says it adds support for a tags interface and tag based filtering, which is the feature you would expect to matter once the data set is large enough that you need to slice it. The last push to main is dated 2023-03-09.

The trial is docker-compose up and a port

Trying it takes three steps: install Docker, run the compose file, and open the port.

docker-compose up

The compose file is worth reading before you run it, because everything is spelled out.

services:
  techmaturity:
    build: .
    ports:
      - "8080:3000"
    environment:
      - RAILS_ENV=development
      - DB_HOST=db
      - DB_USERNAME=postgres
      - DB_PASSWORD=password
    depends_on: ["db"]
  db:
    image: postgres:11.7-alpine
    environment:
      - POSTGRES_DB=techmaturitydb
      - POSTGRES_PASSWORD=password
    ports:
      - "5432:5432"
    volumes:
      - ./tmp/db:/var/lib/postgresql/data

Two services, a build from the local Dockerfile, and the database host reachable by service name. Two details are worth noting for anything beyond a laptop: the database password is a literal in the file, and port 5432 is published to the host as well, so the database is reachable from outside the compose network. The browser URL is the 8080 side of the mapping.

The image pins a frozen bundle and checksums its init

The Dockerfile is built on ruby:2.7-alpine and starts by freezing the bundle, with a comment saying the intent is to throw errors if the Gemfile has been modified since the lockfile.

RUN bundle config --global frozen 1

Since Gemfile.lock is committed at the top level, that combination is deliberate: any dependency change has to go through a lockfile update or the build fails. The package list is long, covering the compilation headers a native gem needs plus nodejs and sqlite development packages, and the second package layer installs openssl and a font package. What is more interesting is how the init process is handled. A specific release of dumb-init is downloaded to a fixed path, then its checksum is verified against a hash written inline in the Dockerfile before the file is made executable.

    echo "37f2c1f0372a45554f1b89924fbb134fc24c3756efaedf11e07f599494e0eff9  /usr/local/bin/dumb-init" | sha256sum -c && \

The final command line runs that binary as the container entry, in front of an entrypoint script which the image copies and marks executable with a world-writable permission. Dependencies are installed in a temporary working directory before the application is copied in, so the layer with the gems does not contain your source.

Production in the image, development in compose

The two deployment shapes disagree about the environment, and neither is hidden. The Dockerfile sets the Rails environment to production as a build step, while the compose file passes development into the running container. That is not a mistake you can read past: it means the image you build locally is configured for production behaviour, and compose deliberately overrides it so you get a development environment from the same image. Port 3000 is exposed inside the image and mapped to 8080 outside. There is also an OpenShift directory at the top level alongside the Docker files, so a second deployment target is anticipated even though the README documents only the compose route.

Contribution asks for one squashed commit

The contribution section is four numbered steps: fork the project, commit your changes to the forked repository, squash the commit, and send a pull request, at which point a team member reviews it. Squashing is the one instruction with a reason behind it, since it matches the single-commit style the repository's own history uses. The supporting files follow the same pattern of a Rails project with a container around it: a Gemfile and a lock file at the root, a Rakefile and a rack config file, an application directory, a database directory, a configuration directory, a tests directory, a vendor directory, a Rubocop configuration for style, a Travis configuration for continuous integration, and an entrypoint script. Running the tests locally is described with Bundler in two steps, installing it and then running the Rails test task.

Editorial conclusion

Use this if you want a shared, visible maturity score across a portfolio of products and can live with defining your own targets, since the model offers standards rather than solutions and was designed to be tailored. Do not expect a migration plan to come with it. Two things to plan for before you run it. The compose file ships database credentials in plain text and publishes both the application and the database port, so treat it as a local trial rather than a deployment. And the container pins a frozen bundle against a checked-in lockfile, so a changed dependency set will fail the build rather than silently resolve.

Frequently asked questions

Official sources

1. Official README
2. Project repository
3. Release notes