Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

PLANET-5443 Add rollback target to Makefile #53

Merged
merged 1 commit into from Sep 11, 2020
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
14 changes: 9 additions & 5 deletions src/Makefile
Expand Up @@ -252,13 +252,11 @@ pull:
docker pull $(BUILD_NAMESPACE)/$(GOOGLE_PROJECT_ID)/$(CONTAINER_PREFIX)-openresty:$(BUILD_TAG) &
wait

deploy: deploy-helm update-meta
deploy: prepare-helm deploy-helm post-deploy

update-meta:
# Set meta on stateless content to max-age 31 days
# gsutil -m setmeta -r -h "Cache-Control:public, max-age=2678400" gs://$(WP_STATELESS_BUCKET) > /dev/null
rollback: checkout copy persist prepare-helm rollback-helm post-deploy

deploy-helm:
prepare-helm:
ifndef NEWRELIC_REST_API_KEY
$(error NEWRELIC_REST_API_KEY is not set)
endif
Expand All @@ -270,6 +268,11 @@ endif
--zone $(GCLOUD_ZONE) \
--project $(GOOGLE_PROJECT_ID)

rollback-helm:
# Rollback to the previous good release
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should work for staging as the previous one should be the one that's on production 👍 Is there a way to find out exactly which version is on production so we can pass it explicitly?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Helm will look specifically for the staging images, because it uses HELM_RELEASE from the env variables.

./helm_rollback.sh

deploy-helm:
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice! Now that this is a separate target, maybe we could make prepare-helm deploy-helm post-deploy into separate job steps instead of a single one with the deploy target. Would make the job output easier to navigate.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I can take that as a separate task, since this would require further changes at the CI templates, but it's a good point. We can break this up even further and also start using name: at our CI steps to make them less cryptic.

# Ensure Helm release is in a usable state
# See: https://github.com/kubernetes/helm/issues/4004
./helm_prepare.sh
Expand All @@ -285,6 +288,7 @@ endif

./helm_confirm.sh

post-deploy:
./activate_plugins.sh

./flush_redis.sh
Expand Down