How To Automate Your Dev Setup

Video

Notes

From the video

• Installing a development environment that is not easily reproducable is technical debt.
• Exceptions that should not be automated:
  • System updates - you don’t want risking things to break in the middle of a development session.
• The bootstrap script (~/.dotfiles/bin/dotfiles) is run as the regular user, but contains sudo ... statements where necessary, e.g. if this is being run on a new system and Ansible needs to be installed.
• ansible-galaxy install -r requirements.yml installs all collections specified in a requirements.yml file.
• Bash scripting titbits: ^e00c9b
  • if ! [ -x "$(command -v ansible)" ]; then ... fi:
    • If the command ansible is not executable (or does not even exist), then …
  • if ! <span class="dead-link">-f "$SSH_DIR/id_rsa"</span>; then ... fi:
    • If the file $SSH_DIR/id_rsa does not exist, then …
  • set -e causes the script to exit immediately if any command within the script returns a non-zero exit status
• The goals of automating your development environment are to
  1. save time, and
  2. prevent mistakes.
  • If maintaining playbooks becomes a burden, take a step back and rethink how you are solving the problem.

From the repo

• By adding "$@" as the last argument to ansible-playbook, arguments can be passed through the bootstrap script, e.g. --tags ... to limit actions.

Resources

• Source code from this video - i.e. just the bootstrap script
• Actual dotfiles of this streamer