coverhound v1.0.0

CoverHound

API Documentation

Deploying

Deploying via CircleCI

CircleCI deploys certain specially formatted branches and/or tags to stages in a deterministic manner.

We have the following types of Circle deploys: 1. Production: + Approval: required + Branch: 'master' + Notification: Git author Slack DM and #commercial-releases Slack + Stage: 'production' + Tag: none + Test: required 2. Tag: + Approval: none + Branch: none + Notification: Git author Slack DM + Stage: Match 2 for tag against regex /^auto-deploy--(\w\d-+)--(\w\d-+)--(\w\d-+)$/ + Tag: /^auto-deploy.+$/ + Test: none

As a convenience to push the correct tag, one case use the bin/auto-deploy-tag script that will tag appropriately and push that tag and that tag only to origin.

Production

Production deploys follow CircleCI deploy case 1.

Preprod and staging

Deploys to preprod and staging are handled by a Capistrano process on your local development machine. To push branch my_cool_code to server my_cool_server, run the following from the project root.

branch=my_cool_code bundle exec cap my_cool_server deploy

Using CircleCI auto deploys for staging

CircleCI deploy case 2 works for staging. Push up your branch to Github. Run the script ~commercial/bin/k8s-staging-tag-and-push-auto-deploy-tag <your server name / namespace >

• Example:

 ~/commercial/bin/k8s-staging-tag-and-push-auto-deploy-tag commercial-s-raik

Using CircleCI auto deploys for preprod

CircleCI deploy case 2 works for staging.

Test

CircleCI will auto-run tests for any build against the default branch and for all pull requests. If you want to run tests on Circle for your current code, run the bin/auto-test-tag script from app root. This will trigger a test run and will notify you via Slack when it has completed.

NB: It will only run tests for the currently checked out branch. It does not take arguments.

Using Docker For Deployment

As a convenience for deployment, a minimal Docker setup is provided to allow you to deploy to staging or preprod even if you have some environment issues. To build the Docker image and deploy, follow these steps. 1. Preparation Add a .env file to your Commercial root directory Add the following enviornment variables: - COMPOSE_PROJECT_NAME=commercial - USER={identifier name for deployments} - BUNDLE_GITHUB__COM={secret key} 2. Get a shell in the container

docker-compose run --rm deploy /bin/bash

1. Execute your deploy and pass current branch git command. NB: This is the exact same Capistrano command from above. That is intentional. Capistrano will be working the same way. Docker is just here to give you a consistent environment.

branch=`git rev-parse --abbrev-ref HEAD` bundle exec cap my-cool-server deploy --trace

Using Docker For Development

Docker is set up to build a fully functional development environment without the need to install dependencies such as Ruby and MySQL locally. Everything you need to develop the application is available through docker images. The following tutorial covers setup and common workflows such as running tests and debugging.

1. Initial setup requirements:

• Install Docker for Mac https://docs.docker.com/desktop/mac/install/ (this is primary used for configuring initial Docker desktop resources but a team license is available if requested).
• Set Docker Desktop resources to at least: 10 GB disk space, 2.5 GB RAM, 2 CPU
• Enable Big Sur virtualization.framework in Experimental Features settings tab
• Run the following bash script bin/sync-settings-repo (see script file for documentation and examples). This script will perform the following actions:
  • Pull latest settings_files repository
  • Copy the necessary configuration settings to your commercial repo
• Confirm that the following ports are not in use:

PORTS=(3000 3306 3001 3035)
for port in "${PORTS[@]}"
do
lsof -i TCP:"$port" | grep LISTEN
done

• Open /etc/hosts and add webpacker as a mapped DNS entry, i.e 127.0.0.1 localhost webpacker

Now that you have all the setup requirements complete you can proceed with initializing the Docker images.

2. Build and Run Docker:

• cd into the containers directory from commmercial root (this is the directory you will run all Docker commands from).
• Running specific images in the background:
  • Some images do not require a tty connection and can thus be ran in the background with the docker-compose up command. Currently, these include db, redis, and webpacker. These images can be run in the background by running docker-compose up -d db redis webpacker
  • It is common during development that a piece of application code is saved and causes a fatal error to one of the above processes. For example, you may forget to return a component from a jsx file and webpack will fail to compile. If you need to view the current output of a process you can either view it in the Docker Desktop logs tab for that specific image or run the docker-compose logs command, e.g docker-compose logs -f webpacker.
• Running specific images in the foreground with a tty connection:
  • It is very common during development that you will need to place breakpoints to halt execution either during a Rails server process or a Sidekiq process via pry or byebug. For this reason, run the following commands in two separate terminal windows: - docker-compose run --service-ports --name=commercial_app_1 app - docker-compose run --service-ports sidekiq

If you are migrating to Docker on a machine that is already configured for development then you should already have your database setup and can begin development. However, if you are setting up a new machine you will need to seed the database which we will cover in the next section.

3. Seed the Database:

• To seed the database we must first be attached to the commercial_app_1 container. In a terminal window run the following: docker exec -it commercial_app_1 /bin/bash
• Once attached run the following commands:
  • bundle exec rake db:drop db:create db:schema:load
  • bundle exec rake db:snapshot:import
• Now you can restart the app container either via the Docker Desktop or with the following command docker restart commercial_app_1

4. Running the Tests

• Commercial currently has two test suites for our Ruby and Javascript source code. Running the JavaScript tests via Jest has not changed by using Docker for development. You may continue to open a terminal, cd into the client directory and run yarn test.
• Running the Ruby test suite, however, does require a different workflow. In order to run any Ruby test you must be attached to the commercial_app_1 container and run that test in the container. An example workflow would look something like

$ docker exec -it commercial_app_1 /bin/bash
$root@823hfcxza:/commercial bin/rails test test/some_awesome_test.rb
... test output

Using Kubernetes Staging local Tools Setup

DevOps will assist you to setup local tools like K9s and AWS credentials