JumpStart – CI, CD, Pair Programming, Estimation and Prioritization

Continuous Integration

This is what happens if a team works in silos and only integrate at the end:

The solution is:
Good user stories and clarification of the user stories
Communications throughout the team
Continuous integration – integrate on every push

Benefits of CI:
Shorter feedback cycles
Transparency: other team members can see other members’ commits
*Never ship broken code (assuming tests are good, and Murphy law does not apply)

Rules of CI:
DO NOT check in on a broken build
Run all tests locally before commit and push
Wait for new commit to pass
Never go home on a broken build
Be prepared to revert to the previous version
Time-box fixing before reverting (time limit of half hour)
DO NOT comment out failing tests
Take responsibility for your breakages (eg: regression bugs)
TDD! (otherwise, there wouldn’t be enough coverage)

Use GIT hooks to prevent pushing on red builds (eg: Husky)

Continuous Delivery

Continuous Delivery is a combination of CI + a pipeline that deploys to a production-like environment for testing.

CI deploys to a staging server and a QA can manually test it.

If there are any bugs, instead of deploying to Prod, the devs can fix them and write more comprehensive tests before pushing again.

Prevents 😭 and 📞

Continuous Deployment (alternative)

Automatic deployment to Production.
The idea is that the more often you deploy, the fewer changes in each deploy, and less breakage.

Not adopted by all companies because:

Needs comprehensive testing
The pipeline must be more advanced and have easy rollback capability.
Goes against operating procedure of some companies (like banks, due to compliance laws).

Additional resources: Continuous Delivery by Jez Humble and David Farley

Circle CI 2.0 Config

Definitions:

Step – the smallest unit of work
Job – a combination of a few steps
Workflow – a few jobs connected together to execute a certain purpose
Sequential jobs – jobs triggered in sequence. eg: Build > Test > Deploy
Parallel jobs – jobs running in parallel

Fan in – wait till multiple jobs to finish before triggering the next job
Fan out – trigger multiple jobs after the current one finishes
Branch-level filtering – deploy off a specific branch
Manual approval – executes a job on manual approval

What to do:

Create different heroku apps for 3 envs: Auto/ Test/ Prod
CI pipeline:
auto run test -> auto deploy to Auto -> manual deploy to Test -> manual deploy to Prod

CircleCI docs

Additional: gocd or teamcity for more complex CI pipeline
For small projects, if you want to deploy both frontend + backend

You can define jobs in the config.yml file.


# .circleci/config.yml
version: 2
jobs:
  build:
    docker:
      - image: circleci/node:10
    steps:
      - checkout
      - restore_cache: # special step to restore the dependency cache
          key: dependency-cache-{{ checksum "package.json" }}
      - run:
          name: Setup Dependencies
          command: npm install
      - save_cache: # special step to save the dependency cache
          key: dependency-cache-{{ checksum "package.json" }}
          paths:
            - ./node_modules
      - run: # run tests
          name: Run Test
          command: npm test
  deploy:
    docker:
      - image: buildpack-deps:trusty
    steps:
      - checkout
      - run:
          name: Deploy Master to Heroku
          command: git push https://heroku:$HEROKU_API_KEY@git.heroku.com/$HEROKU_APP_NAME.git master
workflows:
  version: 2
  build-and-deploy:
    jobs:
      - build
      - deploy:
          requires:
            - build

Circles CI will force deploy to test/ staging a particular commit.
Note: It does not rollback your DB!

Pair Programming using Ping-Pong method

Trying out fizz buzz test

Screen share/ VS live share

Don’ts:

Hog the keyboard
Be passive
Be distracted
Leave your partner hanging
Argue with your partner
Dictate what they should do

Estimations in user story

Estimating is relative, approximate, a group effort, and based on exp, and shared understanding, and is different for different project teams.

Estimates are not set in stone, done right the first few times, and not up to one person.

Humans are better at estimating via relation.

Scale: Fibonacci Sequence, T-shirt size (not 1,2,3,4,5 because the granularity makes it tempting to use ‘time’ as an estimate)

Methods: Planning Poker/ Thrown estimates using ‘Rock, Paper, Scissors’ (to prevent estimates based off previous estimates)

Spikes for ❔❔❔ estimates

A time-boxed experiment for devs to research unknowns

MOSCOW prioritisation

Must Have, Should Have, Could Have and Won’t Have