Deploy Day

Question 1

Sourcegraph

Answer 1

the code search tool we use at Lyft

Question 2

lyftvenv

Answer 2

a command line tool that uses virtualenv (venv) to create an isolated Python environment for each project on your laptop. It allows you to run tests for your project.

Question 3

Tilt

Answer 3

an open source tool used to build and orchestrate dependencies so you can run your services locally. It will start a browser UI dashboard that runs applications locally at Port 10350.

Question 4

Submit Queue (SQ)

Answer 4

a set of GitHub extensions designed to improve development efficiency. It takes commands specifically through comments on pull request. The comment must be on the main pull request page i.e. https://github.com/lyft/favoriteemoji/pull/. Note that commands are not read from commit comments or inline comments on PR diffs.

Question 5

Pre-Commit

Answer 5

manages hooks that call linters. Various errors it might catch include debug statements, extra spaces at the end of a line, and missing end-of-file returns. Pre-commit activates the linters when you commit your files to git with $ git commit or when you run $ pre-commit run –all-files.

Question 6

Linters or Linting

Answer 6

the automated checking of your source code for programmatic and stylistic errors

Question 7

Pytest

Answer 7

a Python unit testing framework. Generally you can run $ pytest tests/ to run all tests in the project

Question 8

Runtime

Answer 8

stores configurations which get deployed to every host in the fleet. It contains settings and feature flags which are checked at runtime, i.e. while the app is running. Caution: Runtime causes some of the most expensive outages and incidents because it can change the behavior of the application without the code change itself.

Question 9

DeployView

Answer 9

uses Autodeployer on the backend to safely manage and automate our deployments. This means we don’t need to manually monitor our deploys through the entire deploying process.

Question 10

Acceptance Testing Framework

Answer 10

runs tests for you behind the scenes when your deployment rolls past staging and will block your deployment if the acceptance tests fail. Blocked deploys will cause the system to generate alerts.

Question 11

Grafana

Answer 11

used as the primary visual tool for monitoring services’ health. Data can be viewed in staging or production mode. There are lots of great dashboards that can flesh out your overall monitoring strategy, or even allow you to debug an incident. You can monitor any sudden changes in the number of calls, response times, etc. in these graphs. There are four types of dashboards: default service dashboards, managed dashboards, deploy dashboards, and code health dashboards.

Question 12

Kibana

Answer 12

tool for exploring and querying logs produced by a service. You can use it to look at the error logs to make sure there’s nothing wrong. Kibana is strongly typed, meaning the value types passed in the kv argument must be consistent for each unique key.

Question 13

Lighthouse

Answer 13

cloud monitoring tool where you can create and monitor charts and alarms

Question 14

Jenkins

Answer 14

an open source implementation of a “Continuous Integration” server written in Java that can be used as a self-hosted option automating the build cycle for any project.