This commit is contained in:
Joey Zhou 2024-05-17 10:02:38 -07:00
Родитель cf8293cdbc
Коммит c0a60458ef
7 изменённых файлов: 14 добавлений и 236 удалений

Просмотреть файл

@ -1,148 +0,0 @@
version: 2.1
executors:
node:
docker:
- image: cimg/node:22.1.0
auth:
username: $DOCKER_USER
password: $DOCKER_PASS
node_with_python:
docker:
- image: cimg/node:22.1.0
auth:
username: $DOCKER_USER
password: $DOCKER_PASS
- image: cimg/python:3.9.7
auth:
username: $DOCKER_USER
password: $DOCKER_PASS
python:
docker:
- image: cimg/python:3.9.7
auth:
username: $DOCKER_USER
password: $DOCKER_PASS
ubuntu:
machine:
image: ubuntu-2004:202107-02
node_with_postgres:
parameters:
postgres_version:
description: "Which cimg/postgres tag to use"
type: string
docker:
- image: cimg/node:22.1
auth:
username: $DOCKER_USER
password: $DOCKER_PASS
- image: cimg/postgres:<< parameters.postgres_version >>
environment:
POSTGRES_USER: postgres
POSTGRES_PASSWORD: 93e389316eaf4ea2be4010d526cc1468
POSTGRES_DB: test-circle
auth:
username: $DOCKER_USER
password: $DOCKER_PASS
orbs:
node: circleci/node@5.1.0
python: circleci/python@1.4.0
heroku: circleci/heroku@1.2.6
jobs:
deploy:
docker:
- image: docker:stable-git
auth:
username: $DOCKER_USER
password: $DOCKER_PASS
working_directory: /dockerflow
steps:
- checkout
- setup_remote_docker
- run:
name: Create version.json
# create version.json per https://github.com/mozilla-services/Dockerflow/blob/main/docs/version_object.md
command: |
printf '{"commit":"%s","version":"%s","source":"https://github.com/%s/%s","build":"%s"}\n' \
"$CIRCLE_SHA1" \
"$CIRCLE_TAG" \
"$CIRCLE_PROJECT_USERNAME" \
"$CIRCLE_PROJECT_REPONAME" \
"$CIRCLE_BUILD_URL" > version.json
- run:
name: Build Docker image
command: |
docker build --tag blurts-server \
--build-arg SENTRY_RELEASE="$CIRCLE_TAG" \
.
- run:
name: Deploy to Dockerhub
command: |
echo $DOCKER_PASS | docker login -u $DOCKER_USER --password-stdin
if [ "${CIRCLE_BRANCH}" == "main" ]; then
# deploy main
docker tag blurts-server ${DOCKERHUB_REPO}:latest
docker push ${DOCKERHUB_REPO}:latest
elif [ ! -z "${CIRCLE_TAG}" ]; then
# deploy a release tag...
echo "${DOCKERHUB_REPO}:${CIRCLE_TAG}"
docker tag blurts-server "${DOCKERHUB_REPO}:${CIRCLE_TAG}"
docker images
docker push "${DOCKERHUB_REPO}:${CIRCLE_TAG}"
fi
deploy_static:
executor: python
steps:
- checkout
- run:
name: Install AWS CLI
command: pip install awscli
- run:
name: Sync static content to S3
command: ./.circleci/scripts/sync-static
deploy_heroku:
# Attempt to deploy, but do not fail job if the push fails. The push will fail if a
# developer has manually pushed a branch, usually for review purposes. This command
# is based on:
# https://github.com/CircleCI-Public/heroku-orb/blob/master/src/jobs/deploy-via-git.yml
# https://github.com/CircleCI-Public/heroku-orb/blob/master/src/commands/deploy-via-git.yml
executor: heroku/default
parameters:
app-name:
description: "The name of the Heroku App"
type: string
steps:
- heroku/install
- heroku/check-authentication
- checkout
- run:
name: Attempt to deploy to Heroku via git push
command: |
set -x
heroku_url="https://heroku:${HEROKU_API_KEY}@git.heroku.com/<< parameters.app-name >>.git"
git push -f $heroku_url $CIRCLE_BRANCH:main
workflows:
deploy-only:
jobs:
- deploy_heroku:
name: Deploy main to Heroku
app-name: $HEROKU_MAIN_APP_NAME
filters:
branches:
only: main
- deploy_heroku:
name: Deploy l10n to Heroku
app-name: $HEROKU_LOCALIZATION_APP_NAME
filters:
branches:
only: localization

Просмотреть файл

@ -1,22 +0,0 @@
#!/bin/bash
# This script is disabled in config.yml because we no longer use logos from the path below.
# Leaving this for reference in case we use CDN for the new logos
set -o errexit -o nounset -o pipefail
cd "$(dirname $0)/../.."
export AWS_SECRET_ACCESS_KEY
export AWS_ACCESS_KEY_ID
aws s3 sync \
--acl "public-read" \
--cache-control "max-age=86400" \
--delete \
public/img/logos/ "s3://${S3_STATIC_BUCKET}/img/logos/"
aws cloudfront create-invalidation \
--distribution-id "${CLOUDFRONT_STATIC_DISTID}" \
--paths "/img/logos/*"

Просмотреть файл

@ -184,7 +184,7 @@ The unit test suite can be run via `npm test`.
At the beginning of a test suite run, the `test-blurts` database will be populated with test tables and seed data found in `src/db/seeds/`
At the end of a test suite run in CircleCI, coverage info will be sent to [Coveralls](https://coveralls.io/) to assess coverage changes and provide a neat badge. To upload coverage locally, you need a root `.coveralls.yml` which contains a token – get this from another member of the Monitor team.
At the end of a test suite, coverage info will be sent to [Coveralls](https://coveralls.io/) to assess coverage changes and provide a neat badge. To upload coverage locally, you need a root `.coveralls.yml` which contains a token – get this from another member of the Monitor team.
End-to-End tests use Playwright and can be run via `npm run e2e`. [E2E-How-To](https://github.com/mozilla/blurts-server/src/e2e) for more info.
@ -220,13 +220,9 @@ When enough translations have been commited, you should merge `localization` int
_**TODO:** explore means to auto-sync `localization` with `main`_
## Deploy on Heroku
## Preview Deployment
We use Heroku apps for dev review only – official stage and production apps are built by the Dockerfile and CircleCI config, with deploy overseen by the Site Reliability Engineering team.
A merge to `main` auto-deploys that branch to Heroku. ~~We also employ Heroku's "Review Apps" to check Pull Requests. These are currently set to auto-deploy: you can find the app link in your GitHub Pull Request. Review apps auto-destroy after 2 days of inactivity.~~
If you encounter issues with Heroku deploys, be sure to check your environment variables, including those required in `app-constants.js`. Review apps also share a database and you should not assume good data integrity if testing db-related features.
We use GCP Cloudrun for dev review – official stage and production apps are built by the Dockerfile and Github Actions. Everything that is merged into `main` will deploy automatically to stage. The ADR for preview deployment can be found [here](https://github.com/mozilla/blurts-server/blob/main/docs/adr/0008-preview-deployment.md)
_**TODO:** add full deploy process similar to Relay_

Просмотреть файл

@ -5,7 +5,6 @@ metadata:
annotations:
github.com/project-slug: mozilla/blurts-server
github.com/team-slug: smozilla/teams/firefox-monitor-engineering
circleci.com/project-slug: github/mozilla/blurts-server
sentry.io/project-slug: mozilla/firefox-monitor
description: Firefox Monitor notifies users when their credentials have been compromised in a data breach.
tags:

Просмотреть файл

@ -1,6 +1,6 @@
# Preview Deployment
- Status: proposed
- Status: Accepted
- Deciders: Monitor team
- Date: 2024-05-08

Просмотреть файл

@ -63,62 +63,20 @@ will be a new version of the Monitor web app on the [Production][prod]
environment. To do this, we first release code to [Dev][dev] and
[Stage][stage].
## Release to Dev
## Preview Deployment
Every commit to `main` is automatically deployed to the [Dev][dev] server, as
long as it can be done with a fast-forward push. Since the
[Great GitHub Heroku Incident of 2022][github-heroku-incident], this is
done from CircleCI using a [service account][service-account].
To push a different branch, you need to add the Heroku app as a remote.
NOTE: give other devs a quick heads-up in Slack before doing this:
- `heroku login`
- `heroku git:remote -a fx-breach-alerts`
Then, you can push your local unmerged branch to Heroku:
- `git push --force-with-lease heroku HEAD:main`
Merges to main will fail to deploy until someone manually resets it to `main`:
- `git push --force-with-lease heroku main`
Every time a PR is open, a docker image is created and deployed to the
preview deployment environment powered by GCP Cloud Run / CloudSQL.
A brand new database is created and schema is migrated specific to that PR.
A brand new Cloud Run service is set up and cleaned up along with the
database at the end of the lifecycle of that PR (when closed or merged).
A preview URL is generated and linked in the PR when the environment is
set up and changes are ready to be reviewed.
## Release to Stage
Every tag pushed to GitHub is automatically deployed to the [Stage][stage]
server. The standard practice is to create a tag from `main` every Tuesday at
the end of the day, and to name the tag with `YYYY-MM-DD` [CalVer][calver]
syntax. This tag will include only the changes that have been merged to `main`.
E.g.,
1. `git tag 2022.08.02`
2. `git push origin 2022.08.02`
E.g., the following `2022.08.02` tag includes only `change-1` and `change-2`.
```mermaid
%%{init: { 'theme': 'base', 'gitGraph': {'rotateCommitLabel': true} } }%%
gitGraph
commit
branch change-1
commit
commit
checkout main
branch change-2
commit
checkout main
merge change-1
branch change-3
commit
commit
checkout main
merge change-2 tag: "2022.08.02"
checkout change-3
commit
commit
checkout main
```
Every commit to `main` is automatically deployed to the [Stage][stage] server
via Github Actions and Jenkins.
### Create Release Notes on GitHub

Просмотреть файл

@ -34,11 +34,6 @@ const netlifyNodeVersion = (await load("netlify.toml"))
.split('NODE_VERSION = "')[1]
.split('", NPM_VERSION')[0];
const circleNodeVersions = (await load(".circleci/config.yml"))
.split("\n")
.filter(line => line.includes("cimg/node:"))
.map(line => line.split("cimg/node:")[1]);
const esbuildVersion = (await load("esbuild.cronjobs.js"))
.split("\n")
.find(line => line.includes("target:"))