For many users, RT evolves far beyond being simply a ticketing system, becoming something more like "The Definitive Choose Your Own Issue Tracking Adventure." There are so many plugins and ways to personalize RT, snowflakes have nothing on RT instances when it comes to uniqueness. And with this great power comes some interesting challenges for us when updating RT with new features while maintaining all of those interesting features and options.
One of the challenges we face at Best Practical is managing the wide number of supported versions and platforms for Request Tracker. When it comes to customer driven development, not only do many of our customers have different versions of RT, but many different customizations thereof. Just confirming a single extension works across 3 major versions of RT can be a challenge.
Docker has emerged as a powerful tool to reliably spin up entire working environments in Linux. Docker containers make developing and testing across versions and platforms much easier. Some of our engineers create a set of base container images for each of the Linux distributions and databases we support. Then they volume mount a common source code repository across each of the instances. This lets them run RTs tests against each of the environments on a local development machine.
When we do work for a particular customer, we can checkout and build the git tags associated with their deployment. After installing their particular customizations, we can then snapshot the container for future reference. If the customer comes back weeks later with a new feature request, or just wants some changes, we already have a representative development environment in which to test the desired changes.
Even for mainline RT development, Docker containers make small tasks like bug fixes easier to develop. If we're working on a feature we want to release for RT 4.2 and RT 4.4, we need to verify that a branch plays nicely on both. And while our CI server tests against many different environments, a full test run can take quite a while to complete. Before pushing code to the test server, we usually run tests locally. With a set of 6 docker containers, we can run unit tests against both RT 4.2 and RT 4.4 backed by 3 different database configurations on a local machine. This can reduce turn around time on updates from days to hours.
Request Tracker, like much enterprise software, is primarily used in mission critical operations. Typical deployments represent years of knowledge, configuration, and customization to get things working smoothly. Tools like Docker help us manage RT's flexibility and rich set of options while still adding new features in each new release.