Program Increment Status

Program Increment Status - CWDS DevOps Engineering

This page contains information about our Program Increment Priorities, Goals, and Results. This is a living page and will be updated for each PI. We keep PI epics and major deliverables in our GitHub Project, and our projects are updated for each Sprint. Specific details of our daily work is kept in Pivotal Tracker.

We are currently wrapping up PI-2, and have started planning for PI-3.

Contents

• Program Increment 3 (PI-3)
• Program Increment 2 (PI-2)
• Program Increment 1 (PI-1)

---

Program Increment 3

Please refer to our PI-3 Project for epic-level details

Goals and Objectives

GOAL: Provisioning and Configuration

• Identity Management
• Environments
  • Integration (New)
  • Development Preview (New)
  • Perf (Rebuild for CALS)
  • Prod (Rebuild for CALS)
  • Sandbox (Rebuild for CALS)
  • Proxy Networks (network interface adapter/proxy to CDT)
• Security
  • Prepare for Prod access
  • Continue hardening the environment
  • Patch Management

Challenges Ahead

• External Dependencies are biggest challenge, and most-frequent impediment
  • Networking - Connecting AWS cloud to CDT with Direct Connect
  • AWS Region - The NorCal Region is a Tier 3 region, and thus does not offer all of the services of a Tier 2 (e.g. Oregon) or Tier 1 (e.g. Virginia) regions, meaning basic services such as the Web Application Firewall have to be built/implemented by CWDS rather than leveraging the service offering from Amazon.
• Team Capacity
  • Starting off the PI with only two engineers. Four new engineers will join in PI 3.4

Major Achievements

Lessons Learned

1. Multiple Ruby on Rails Apps in the Same Domain

Ruby on Rails loves to put everything in the root ("/") of a domain (see also, Asset Pipeline). We have multiple RoR containers that need to hang off the same domain without interfering with each other. We found that the default configuration causes conflicts with the /assets of each app. The way we handled this was to use the Rails config.relative_url_root parameter to give each app its own namespace, which can be set at build and deploy time.

2. Importance of Setting up Development Environment to match the production environment

Developers often work in a space that works fine for their particular component, but the first time they get to see how what they're building runs into/collides with other apps is in our "Pre-Integration" environment. This seems obvious, but our "environment" is constantly evolving, which makes this a challenge to keep everyone in sync. TODO: Setup a Docker Compose file that allows developers to deploy a local development/testing environment on their laptops that functions comparable to the way their app would behave in our application environments.

---

Program Increment 2

Goals and Objectives

Key Activities: Deploy and Provision for Project, Devs, and Ops

0. Hold ground, keep Prod Up
1. Pay down debt
2. All Environments Have Same Structure
3. Enhance Security so we can support Web
4. Measure Everything
5. Improve work and progress visibility and documentation.
6. Reduce Unplanned Work, and limit planned work to User stories
7. When given the choice between two equally valuable outcomes, choose the one that makes future change easier

Major Achievements

• Completed Sandbox environment
• Completed first stage of Environment Build automation with CloudFormation and Ansible

Lessons Learned

---

Program Increment 1

Goals and Priorities

• Environments:
  • INT01 (New)
  • PERF (New)
  • PROD (New)

Lessons Learned

1. All Environments Must Match!

• We ran into a lot of issues when we moved from INT01 (Intake Integration) to PERF (Performance).

2. We learned A LOT about Infrastructure as Code!
3. Even small teams can benefit from a Scrum Master!

• We started off the team as four engineers, back in November, but over the course of the PI one of us moved into the Service Manager position, and struggled to keep up with planning, working with the project, and coordinating the effort and direction of the team.
• We now have a full time scrum master and service manager, with three engineers. This balance of roles is working much better.