Prior to 2018, our team had no centralized services to support the development teams and the need for traditional Software Development Life Cycle (SDLC). Teams needed to support their own needs by procuring SaaS-based solutions and standing up their own services. Tools were spread across many projects and required intricate project budgets and many work force hours to maintain.
To support the SDLC, teams needed to determine a set of shared services that support the following: Tasking, Design, Coding, Building, Collaborating, Testing, Packaging, Scanning, and Deployment. The services needed to provide users with a 99% availability Service Level Objective (SLO). Additionally, the systems had to meet security requirements, monitoring abilities, and support the developers’ needs both in terms of growth and simultaneously providing a stable, reliable baseline while rapidly changing to support emerging business needs.
This complex set of requirements demanded an Agile approach while depending on automation testing and Continuous Integration / Continuous Delivery (CI/CD) practices. Additionally, we required services delivered as Infrastructure as Code (IaC). Finally, any instance had to be ephemeral yet completely repeatable with zero data lost.
As part of the Agile Transformation efforts, Parsons IT created a set of shared DevOps services for Parsons Commercial efforts to support tasking, issue tracking, and product backlog. Our first service was Jira in November 2018. In early 2019, we deployed Slack to support collaboration with the various tools in the DevOps suite. To provide support, teams delivered Opsgenie to the Parsons IT, which allowed on-call rotations and after-hours escalation. In March 2019, we needed to support the ability to have version control on our source code, so we stood up Bitbucket as a shared “git” repository. Lastly, to help capture design and other technical information, we added Confluence to the available toolset. Together, these systems represent the start of the DevOps offerings for the Parsons Commercial Computing Environment.
We envisioned another network that provided a set of DevOps services to Federal users who did not need the protection of an air gaped network or who required cloud compute resources. The establishment of this set of services was part of the Modernize Enterprise Hosting Capability (MEHC) effort because it involved the replacement of systems in the High Security Environment (HSE) located in the Dallas Data Center (DADC) and the systems used by our Legacy Polaris Alpha and OG Systems developers.
We had to consider our federal teams and what kind of environment was needed for them to work effectively while also being secure. Similar efforts kicked off to build FedNet® Secure, an air gaped network with DevOps services and compute resources available. This would lead to the consolidation of two secure internal network systems.
To better support Product Development across the company, we stood up three new and complete Product Development Environments (PDE) that support the efforts. In addition, we simplified the names of each environment: Open, Protected, and Secured.
Open Product Development Environments (OPDE) have no controlled data information (CUI, ITAR, DFARS, PII/PHI) stored with the open environment. Open environments exist in commercial space; IT supports this space. The teams that have no federal regulatory requirements (such as DFARS, CMMC, citizenship) utilize this environment daily on the Parsons network. Our team utilizes Jira, Confluence, Bitbucket, and Slack for teams in an open environment to develop products and services for our customers.
The Protected Product Development Environment (PPDE) fills a gap between the existing Open PDE and the Secured PDE. The Protected PDE simplifies the development experience of any developer with tighter compliance requirements by providing a comprehensive suite of DevOps tools and resources that provision on-demand. Additionally, this secure environment connects to our Federal network and provides a data boundary, is DFARS compliant, and CMMC 2.0 level 2 compliant. The Protected PDE delivers a set of DevOps Tools and is part of the larger Protected Computing Environment (PCE) that offers a Self-Service Environment to product teams. Together these solutions provide two capabilities needed by modern product teams:
DevOps Tools provide a suite of centrally managed, highly available Development Tools to product teams at no additional cost. These tools come with a dedicated team of Site Reliability Engineers (SRE). They work together with the Security Operations Center (SOC) and Network Operations Center (NOC) to ensure the tools operate with the highest availability and resilience needed by our product teams. In short, the Protected PDE provides DevOps Tools as a Service to our teams and our sub-contractors capable of handling CUI data
The Self-Service Environment grants teams direct and easy access to cloud resources to operate safely in the cloud. The environment supports both advanced cloud-based development and burst capabilities for traditional workloads. These workloads are entirely provisioned by the projects and development teams, with their charges directly passed back to the project
The PPDE, together with the PCE, reduces the heavy lifting for the product and project development teams to be able to identify and work on the following:
The PPDE provides users with dedicated instances of Bitbucket, Jira, and Confluence, along with a PPDE workspace in Slack. Furthermore, the PPDE provides two Continuous Integration / Continuous Delivery (CI/CD) options to assist with automated build processes: Jenkins and Gitlab. In addition, the PPDE also houses enterprise instances of Artifactory (including JFrog X-Ray), a binary artifact repository and security scanner, SonarQube for performing Static Code Analysis, and NetSparker for providing Dynamic Code Analysis of websites. We configure these three enterprise products to allow OPDE users to leverage these services without needing to stand up separate instances in the OPDE.
Our most secure environment, FedNet® Secure, supports the needs of a Secure Product Development Environment (SPDE). FedNet® Secure consolidates multiple disconnected Federal development networks into a DFARS 252.204-7012 / NIST SP 800-171 compliant enclave. Parsons FedNet® Secure is a “closed” network with no Internet access. It has defined and restrictive borders. Additionally, it has infrastructure physically isolated from any Internet-connected device. This prevents our teams from using cloud-based services (such as IaaS and Saas). FedNet® Secure must host and maintain any applications or services needed for operations and development that support our teams. The network extends to all of our Federal locations where DevOps capabilities are required.
Our IT teams continue to expand and improve on the various PDE environments. These PDEs host many of the most common software development tools and services our contracts need to design, test, and deliver code to a client. Having the software environments, tools, and services already deployed and certified allows our markets to bid, win, and immediately begin work on software contracts without deploying or administering their own individual PDEs. This gives our team higher profit margins and a distinct competitive advantage as an industry leader.