plombardi89
commented
6 years ago Forge Feature <-> Role Mapping
Roles
Below are the roles that are mapped. A role is an abstraction that describes some set of responsibilities a person a team has and it is expected that many Forge users could have multiple roles, for example, a Forge user might be both a product developer as well as administrator for their services or some other combination.
Role: Operations Engineer
An operations engineer or ("op") ensures an Area of Responsibility ("AoR") is operating normally. An AoR in this context could be anywhere from a single microservice in the production environment to the entire production environment.
As such an operator is generally:
- The first person or team to know when their AoR fails.
- The first responder when their AoR begins to fail or is failed.
- The initial diagnostician for a problem.
Role: Product Engineer
A product engineer ensures product features are implemented and issues are fixed. A product engineer might be responsible for anything from a single microservice to all the services that are exposed to the end-user.
Role: Platform Engineer
A platform engineer creates or assembles build and introspection tools that make Product and Operations Engineers more productive.
Role: Technical Lead
Note 1 (2018-05-14) A technical lead is a bit of a meta-role in that it is unlikely a tech lead is purely a decision maker that is to say they are usually composites of the (operations, product, and platform) engineers that have seniority and expert knowledge of an Area of Responsibility.
Note 2 (2018-05-16) Upon reflection it does not seem a technical lead is a role.
A tech lead:
The person responsible for the long term velocity, throughput or quality of the project, for example, that might, for example mean developing templates or project archetypes that can be easily cargoculted or helping the team make "sane" technical decisions.
Role: Manager
Has a high-level understanding of business objectives for their team and unifies the Operations, Product and Platform roles generally to ensure productivity is high.
Existing Features
This section is organized in the form of features in service of each role.
Role: Operations Engineer
forge list to track down App info
-
The
forge listcommand makes it possible for an Operations Engineer to see what is running in a cluster at any given moment. It makes it easy to track down the source and build metadata for a running service. The most useful aspect of this feature is that it can hopefully point an Ops Engineer in the direction of where more documentation is located if a service fails (e.g. to get the repair playbook or README) if it exists. -
Forge automatically populates metadata into manifest annotations that make it possible for the above functionality to work.
-
Gap The utility of this feature is lessened when the manifests the information is embedded in are destroyed. This makes recovery in some catastrophic situtations very difficult.
-
Gap The information is static which makes it possible to become out of data if, for example, the source repository is renamed.
Assists with: Diagnostics
Role: Product Engineer
forge build containers (fast docker builds)
This command is usually implicitly used as part of forge deploy but the utility of fast docker builds is worth discussing independent of deploy. As a product engineer its possible to be working on a service or many services that have slow compilation or dependency resolution mechanisms. If your goal is to iterate fast on several services at once then this is really useful because Forge can help you do incremental compilation of your images and then
Persona: Tech Lead
As a technical leader you want to make development as cargo-cultable as possible. To this end forge deploy is great for a single service because it makes the process of going from nothing to something easy to reproduce.
Gap - No easy way to assemble a working environment of several services (e.g. docker compose esque environment setup). Best way is to currently manually git clone several repositories and then forge deploy from the root.
Gap - No easy to create "vetted" archetypes for projects that encode sharable best practices.
Role Scenarios
Still In Progress
Forge has a number of existing features already and there are a number of desired features that are wanted from various users. The goal of this task is to map the entire set of Existing and Desired features to the roles as fleshed out in https://github.com/datawire/forge/issues/193
COS: