A config file for a concept service that controls the entire release process.

release-manager-config-concept.yml

release:
  id: 2017.05
  environment: aws-dev  # maybe unnecessary but terraform and iron need to know somehow
  tasks: # defaults to serial execution

  - description: pre-release db migrations
    # NOTE: Db migrations dont have to come first; they can occur anywhere, but this is an example of when they typically do batch up at the beginning
    parallel: true
    tasks:

    - runner: sql
      database: media_platform  # or maybe a connection string
      script: 001_some_schema_change.sql
      rollback:
        # runner and database assumed same
        script: rollback_001_some_schema_change.sql

    - runner: liquibase
      # other args...

  - description: backend services
    parallel: true
    tasks:

    - runner: terraform
      service: mp-das
      ami: ami-65bad78  # Or maybe it looks up the tags?  but this way makes it explicit and repeatable

    - tasks:  #example of embedded orchestrated sequence (serial within parallel group)

      - runner: terraform
        service: sso-auth
        ami: ami-98bcf52

      - runner: sql
        databse: sso
        script: 010_some_interim_data_migration.sql
        rollback:
          script: rollback_010_some_rollback_script.sql

      - runner: terraform
        service: core-admin-server
        ami: ami-02efd67

  - description: apis
    parallel: true
    # ...

  - description: apps
    # ...

  - description: post-release data migrations
    parallel: true
    tasks:

    - runner: node
      script: 100_some_data_migration.js
      # I'm thinking either we'd have some standard set of libraries pre-installed or point to directories with package.jsons and an index.js

  - description: engines
    parallel: true
    tasks:
    - runner: wercker
      application: task-google-translate
      pipeline: deploy-prod  # Possibly pull automatically from the environment

    # ...

Most nodes in this file would either have a tasks or runner attribute.

The tasks would be a list of tasks to execute for that step (in parallel if specified). The runners would have other attributes specific to the provider they represent.

We would write glue code per "runner type" to:

1. define the options it takes
2. orchestrate the execution
3. specify what kind of UI to show on the release dashboard (e.g. our crazy set of columns with checkboxes for the terraform or iron runners, a simpler run/not-run UI for the sql runners).

Concept runners represented in this example:

• sql: Raw SQL scripts with a concept of how to connect to our various databases
• liquibase: Kick of a migration through liquibase
• terraform: make plan/make apply-saved-plan through terraform
• node: Run a node script (used for data migrations)
• wercker: Run a wercker pipeline (for deploying engines and other stuff)