diff --git a/.travis/functions.sh b/.travis/functions.sh index a11b113e5..c4785fd1f 100755 --- a/.travis/functions.sh +++ b/.travis/functions.sh @@ -90,19 +90,20 @@ _upload_package() { _deploy() { if [ `_is_tagged` == "1" ]; then - if [ "${SPARK_RELEASE_NOTIFICATION_KEY}" != "" ] && [ "${SPARK_RELEASE_NOTIFICATION_HOST}" != "" ]; then - echo -e "${SPARK_RELEASE_NOTIFICATION_KEY}" > release_notify.key - chmod 400 release_notify.key - if ssh -o StrictHostKeyChecking=no -i release_notify.key "${SPARK_RELEASE_NOTIFICATION_HOST}" `_get_package_version` `_get_package_url`; then - echo; echo "OK" - return 0 - else - echo; echo "ERROR" - return 1 - fi - else - echo "skipping release notification because no SPARK_RELEASE_NOTIFICATION_KEY or SPARK_RELEASE_NOTIFICATION_HOST variables" - fi + echo "skipping release notification because we are using autoscaling groups and launch configurations now" + # if [ "${SPARK_RELEASE_NOTIFICATION_KEY}" != "" ] && [ "${SPARK_RELEASE_NOTIFICATION_HOST}" != "" ]; then + # echo -e "${SPARK_RELEASE_NOTIFICATION_KEY}" > release_notify.key + # chmod 400 release_notify.key + # if ssh -o StrictHostKeyChecking=no -i release_notify.key "${SPARK_RELEASE_NOTIFICATION_HOST}" `_get_package_version` `_get_package_url`; then + # echo; echo "OK" + # return 0 + # else + # echo; echo "ERROR" + # return 1 + # fi + # else + # echo "skipping release notification because no SPARK_RELEASE_NOTIFICATION_KEY or SPARK_RELEASE_NOTIFICATION_HOST variables" + # fi elif [ "${TRAVIS_BRANCH}" == "master" ] && [ "${TRAVIS_PULL_REQUEST}" == "false" ] && [ "${SLACK_API_TOKEN}" != "" ] && [ "${SPARK_DEPLOYMENT_HOST}" != "" ]; then if [ ! -f deployment.key ]; then echo -e "${SPARK_DEPLOYMENT_KEY}" > deployment.key diff --git a/docs/development/releases-and-deployment.md b/docs/development/releases-and-deployment.md index 8b7d97759..d8ec4568e 100644 --- a/docs/development/releases-and-deployment.md +++ b/docs/development/releases-and-deployment.md @@ -19,10 +19,58 @@ * merge the change in package.json to master * don't forget to push! * now, you can publish the release in GitHub -* Whenever a release is published, the production server is updated with the release name and package but does not deploy it * notification is sent to slack #sparksystemlog with the release name - notifying you that it's ready for deployment -## Deploying to production +## Deploying a published release +* get the package_url from the slack notification in sparksystem-log channel +* log-in to AWS +* if migrations are needed + * open the latest spark-production launch configuration (e.g. spark-production-v2.2.2) + * copy the userdata script + * modify the DEPLOYMENT_PACKAGE_URL to the new url you got from sparksystem-log + * launch a new instance directly (without the autoscaling group) using this userdata script and based on the AMI of the launch configuration + * ssh into this new instance + * `cd /opt/spark/latest` + * `./knex migrate:latest` + * if migrations worked, you can terminate this instance +* after migrations ran: + * duplicate the latest spark-production launch configuration + * edit the userdata and modify the DEPLOYMENT_PACKAGE_URL to the new url you got from sparksystem-log + * save the new launch configuration with the version in the launch configuration name + * edit the spark-production autoscaling group - to use the new launch configuration + * raise number of instances to launch new instances with the new version + * wait for new instance to be launched + * reduce number of instances back to normal + +## Deploying a hot-fix release +(assuming you have Git remote named midburn which points to midburn repo) +* make sure you have all tags from midburn + * `git fetch midburn` +* go to the relevant release which is currently deployed on production + * `git checkout v2.2.2` +* if there is no production branch - create a new one + * `git checkout -b production` + * `git push midburn production` +* if there is already a production branch - best to delete and create again (assuming it's only used for hotfixes) + * `git branch -D production` + * `git checkout -b production` + * `git push --force midburn production` +* start working on your feature from this production branch + * `git checkout -b your-feature-branch-name` +* make you changes as you normally would, on your feature branch, push to you fork etc.. +* when you open the pull request, modify it to merge to production branch (instead of the default which is master branch) +* once pull request was merged to production branch - + * create a new draft release and modify it to be a release for production branch (instead of the default which is master) + * it's common practice to increment the path part of the version (the last part) when making a hotfix + * also, worth to note in the release notes that it's a hotfix release +* publish the release and deploy normally as any other release + +**important** +* after you deploy your hotfix, it's important to backport (merge) these changes to master as well +* you can open another pull request from your feature branch - but this time for the default master branch + +## (deprecated) Deploying to production using slack +**This procedure doesn't work any more, see above for deploying using the autoscaling group** * Assuming you user is authorized (see below how to authorize) * Type in slack: `/spark-deploy RELEASE_TAG_NAME` * where RELEASE_NAME is a published github release tag name diff --git a/package.json b/package.json index a382486e0..58288c050 100644 --- a/package.json +++ b/package.json @@ -23,7 +23,7 @@ "//download": "download a deployment package from private slack url", "download": "curl -H \"Authorization: Bearer ${npm_config_token}\" -g \"${npm_config_url}\" -o \"${npm_config_file}\"", "//deploy": "prepare the directory of an extracted deployment package", - "deploy": "echo SPARK_DEPLOYMENT_TIME=\\\"$(date\"+%F%T\")\\\" >> .env", + "deploy": "echo SPARK_DEPLOYMENT_TIME=\\\"$(date \"+%F %T\")\\\" >> .env", "//lint": "runs static analysis using eslint", "lint": "./node_modules/.bin/eslint ." },