Skip to content
This repository has been archived by the owner on May 30, 2023. It is now read-only.

Home

Jump to bottom
Meyric Rawlings edited this page Nov 26, 2021 · 9 revisions

Measuring development practice

Welcome

Thanks for stopping by!

We are trying to build a set of tooling to help understand our development practice.

We have done a bunch of work on this subject and there is work spread about and some decisions to be made to really get going.

This repo aims to be the one place (see ADR 0002) for us to collaborate on this work and pull all the great work we have already done into one place.

Below is everying I could find and having reviewed it, it feels like we are in a good place to make the following decisions:

  • we will use GitHb actions
  • we will use Ruby as our scrtipting langauge

Also below is a very rough high level view of how this could come together as a set of actions that are really simple to add to a project.

Whilst this repo is a good way to keep async communciations in one place, there is still room for more synchronous communication when needed:

Slack

https://dxw.slack.com/archives/C02FF56AFFV

In person

🧑‍🤝‍🧑

Is you do work away, let's commit to keep this repo up-to-date in some way to keep hold of the great good work!

Aims

  • Measure and monitor interval between production deploys
  • Measure and monitor how long code takes between first local commit to being live on production
  • Measure and monitor some metrics about pull requests
    • Total changes
    • Changes per commit

Dependencies

  • Projects we want to measure need to expose an endpoint with the current SHA on production

Some of the repos

https://github.com/dxw/deployment-frequency

https://github.com/dxw/detect-a-deployment-hackday

https://github.com/dxw/production-lead-time

https://github.com/dxw/detect-a-deployment-hackday

https://github.com/dxw/measure-pr-stats

Tooling we can use

Questions

  • if we build a GitHUb action are we limiting where we can use this, CAEW for example does not use GA?
  • if we use a GA javascript runs natively so is fast, but a large number of devs gravitate to Ruby which would have to run in a container - there is a decision here about the langauge
  • can we stil use GA as Github knows when we pushed to the branch that triggers a deploy and then when that bulid completes?
  • How far did we get?
  • Based on the existing spiky work, are there ways we want to proceed and maybe ways we don’t want to choose?
  • One repo or several?
  • Which path do we choose for gathering information about projects and deployments?
  • Poll a healthcheck to find out information about the current live version
  • Write a GitHub Action that deployments are supposed to call to send info about the current live version
  • Which of the aims do we take on as a project first?

Thoughts

It feels like a good shape for this would be a custom action that we can just use, perhaps before and after actions that run around the deploy? It might look a little like this pseudo code in use:

on:
  push:
    branches: [ main ]
jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - name: PR stats
        uses: dxw-actions/pr-stats@v1
        
      - name: Before deploy
        uses: dxw-actions/before-deploy@v1
        
      - name: Checkout code
        uses: actions/checkout@v2

      - name: Deploy
        id: deploy
        run: |
          echo "faking a deploy"
          sleep 5
          echo "fake deploy finished"
          
      - name: After deploy
        uses: dxw-actions/after-deploy@v1

Our three goals here are then loosly contained in acitons:

pr stats

before deploy

after deploy

Clone this wiki locally