-
Notifications
You must be signed in to change notification settings - Fork 0
github workflow
This page describes how the CWDS DevOps Engineering (DOE) Team uses GitHub to manage infrastructure code. We try to adhere to the same workflow as the application code development teams (we're an infrastructure code development team). One of our key principles is Infrastructure as Code. As a rule, anything we do to setup our environments is done using Ansible, CloudFormation, and occasionally good old shell scripts. Manual changes may be made in non-prod environments, with the understanding they are temporary and could be undone as soon as one of our infrastructure scripts runs.
At this time, CWDS is not making its infrastructure repositories public, the way we do with our application code, due to security concerns. We are looking into ways to make our code available to interested parties in Q3 2017, once we have had time to put a request/review process together. We will make some code available in the DevOps repository on a case-by-case basis so that we can share back useful pieces of code we develop.
- DevOps -- Our public-facing repository includes useful stuff like this wiki, our public issues log, as well as some useful code and public keys that are useful for sharing the story of "What" we do, without exposing the specific (and sensitive) "How".
- Ansible -- Configuration Management code. We keep all playbooks and roles in one directory structure, and maintain separate inventory directories for each environment. This allows us to reuse our Ansible scripts across any environment, tailored for the specific needs and configuration of each environment.
- CloudFormation -- Infrastructure Code. We use CloudFormation to create our AWS networks, servers, and more.
We make every effort to keep branches to a minimum, and prefer that all code be in the master branch. We have found, however, that we often branch for an environment we are building or changing, and all the user stories we work on for that environment get merged into that branch. We are working toward the goal of doing everything out of the master branch, and then using story-specific branches.
We use GitHub Pull Requests to merge features/changes into the environment branch. Pull Requests should be created any time code is changing for a user story, which allows us to have explicit peer review of all code changes.