The Administrative Office (AO) of the US Courts provides information technology (IT) support for software development, systems engineering, maintenance, and operations of national information systems for all federal courts. The portfolio of applications developed by the AO are in support both the goals and mission of the federal judicial branch and are directly associated with the daily operations of the systems currently in use within the judiciary’s Bankruptcy Courts, District Courts, Appellate Courts, Defender Services Offices, and Probation and Pretrial Services Offices.
To help support this mission, ActioNet has partnered with the US Courts to mature their agile software developed practices and integrate selected DevOps best practices. US Courts had initiated both Agile and DevOps practices prior to ActioNet’s contract but once ActioNet joined this effort, we focused on defining not only the maturity map but also executing both a culture and technology shift. For the first year we focused on practices that included automated testing, continuous integration, integrated configuration management, and continuous deployment (to non-production environments).
One of the most common starting points for groups looking to take advantage of the benefits from Agile and DevOps is with the build out of an automated test suite. Within most modern development approaches there is a paradigm shift from testing being completed by a separate IV&V group to testing being the responsibility of the core development team.
Automated regression testing has been adopted by US Court agile teams and our implementation has been extended to test-first approaches such as test-driven development (TDD) and behavior-driven development (BDD). Part of the maturity model developed for US Courts includes assessment and improvement of what we call the “testing pipeline”. The testing pipeline includes all testing executed prior to production deployment including but not limited to; unit testing, integration testing, functional, security, performance, and acceptance to name a few. The initial focus for our team was to build out unit testing as it is generally overlooked and as a best practice it should represent over 70% — 90% of your testing suite.
Over the course of our contract with US Courts we have accessed the current approach, developed a testing pipeline maturity strategy, and partnered with various groups across the organization to implement. We work with our clients around tradeoffs (such as when deciding to focus between regression testing or developing new feature based test cases) that are common when implementing test automation on legacy software.
Continuous Integration (CI) is a development practice that requires developers to integrate code into a shared repository several times a day. Each check-in is then verified by an automated build, allowing teams to detect problems early. CI is one of the more exciting agile development practices (at least from a developer’s perspective) that is typically associated with DevOps. At our US Courts client the general idea is to integrate small changes often. Integrating a large change is a disproportionately large amount of work. CI enables/encourages developers to develop a high-quality working solution safely in small, regular steps by providing immediate feedback on code defects. CI is different from automated testing and continuous deployment in that this portion of the DevOps pipeline is focused on the build and integrated configuration management (described below).
Integrated Configuration Management
The ActioNet US Courts integrated approach to configuration management (CM) involves development teams not only apply CM at the application level but we also consider production configuration issues between application/solution and the rest of the courts organizational infrastructure. This can be a major change for some developers because they’re often used to thinking about CM only in terms of the solution that they currently work on instead of focusing on the bigger picture of integrating DevOps approach for the developers need to be enterprise-aware and look at the bigger picture. How will their solution work with and take advantage of other assets in production? Will other assets leverage the solution being developed? The implication is that development teams will need to understand, and manage, the full range of dependencies for their product.
The courts, like other groups, have a series of lower (non-production) environments, each serving a specific function where code needs to be promoted through before being released into production. Our implementation of continuous deployment here extends the practice of continuous integration. With continuous deployment, when our integration is successful in one sandbox, changes are automatically promoted to the next sandbox, and integration is automatically started there. This automatic code promotion, which is orchestrated through a toolset is automated from beginning to end, except for when a manual verification is required at the transition point. Continuous deployment, such as what has been implemented at US Courts, enables development teams to reduce the time between a new feature being identified and being deployed into production and enables the business to be more responsive.
ActioNet, and our clients at US Courts understand that DevOps is not a new technology or a product. DevOps means a lot of different things to a lot of different organizations. ActioNet’s approach and goal for US Courts is very much about continuous feedback loops, continuous collaboration, continuous delivery, and continuous innovation.