Environments of our app

# Environments of our app We currently deploy to three different servers with three different environments, Alpha, Beta and Production. Our Alpha environment is for our development to test new features, fixes and run our tests. It has its own database which is dropped and restored everytime our tests run and only the development team has access to it. Our Beta environment is for our new releases and features that our clients are eager to use or a feature that was specially developed for a client. It may have bugs due to client's demand and it shares the same database as our Production environment and our clients do have access to it ## Deploy to our environments ***Do not restart puma manually! It will change Puma's PID and deploy will fail due to this change! If it is strictly necessary, do not forget to update shared/pids/puma.state file with Puma's new PID!*** ***If deploy fails due to ExecJS error, please see the issue https://github.com/rails/execjs/issues/81*** #### Alpha Deploy on alpha branch is triggered every time the branch alpha receives a push. It currently uses Capistrano to deploy a new release, so it is responsible for creating a new release folder, linking it to our current folder, pull code from repository, install our gems, precompile the assets and restart Puma. All of this is done automatically by capistrano. After deploy is done, it will trigger a new job on Jenkins to dump our alpha database and restore it. Once it is concluded, it will trigger another job on Jenkins to run our tests. #### Beta Deploy on beta branch is triggered every time the branch beta receives a push. It currently uses Capistrano to deploy a new release, so it is responsible for creating a new release folder, linking it to our current folder, pull code from repository, install our gems, precompile the assets and restart Puma. All of this is done automatically by capistrano. If tests are not passing, the deploy on beta will fail. #### Production Deploy on production branch is triggered every time the branch master receives a push. It currently uses Capistrano to deploy a new release, so it is responsible for creating a new release folder, linking it to our current folder, pull code from repository, install our gems, precompile the assets and restart Puma. All of this is done automatically by capistrano. If tests are not passing, the deploy on production will fail. ## Jenkins Flow #### Alpha - Deploy is triggered by push event on alpha branch, running the following code: - `source ~/.bashrc` to load rvm - `bundle install` - `bundle exec cap alpha deploy` - Deploy finishes and triggers the AlphaRestoreMongoDB job which runs the following command to drop and restore database: - `mongorestore --drop --db decision_makers_development /home/deploy/dump/03_07_19` - After database is restored successfully, it triggers FunctionalTestFreeStyle job which runs the commands below: - `chmod +x $HOME/workspace/FunctionalTestFreeStyle/resources/Drivers/chromedriver_linux` - `mvn clean test -U -P alphatests` ### Beta - Deploys is triggered by push event on beta branch and it triggers FunctionalTestFreeStyle job. - After FunctionalTestFreeStyle succeeds, it runs the following command: - `bundle install` - `bundle exec cap beta deploy` - If FunctionalTestFreeStyle job fails, capistrano command is not executed and deploy is cancelled. #### How to disable FuncionalTestFreeStyle job To disable the necessity to FuncionalTestFreeStyle job pass before deploying to Beta and/or production, follow the steps below: - Go to project's configuration - Scroll down to Build, click on the red ***X*** to remove the build trigger and save #### How to enable FuncionalTestFreeStyle job To enable the necessity to FuncionalTestFreeStyle pass before deploying to Beta and/or Production follow the steps below: - Go to project's configuration - Scroll down to Build - Click on `Add build step` - Select `Trigger/call builds on other projects` - Move the `Trigger/call builds on other projects` box ***above*** `Execute Shell` box - On `Projects to build` field enter ***FuncionalTestFreeStyle*** name - Select `Block until the triggered projects finish their builds` checkbox - On `Fail this build step if the triggered build is worse or equal to` select ***UNSTABLE*** - On `Mark this build as failure if the triggered build is worse or equal to` select ***FAILURE*** - On `Mark this build as unstable if the triggered build is worse or equal to` select ***UNSTABLE*** ### Production - Deploys is triggered by push event on master branch and it triggers FunctionalTestFreeStyle job. - After FunctionalTestFreeStyle succeeds, it runs the following command: - `bundle install` - `bundle exec cap production deploy` - If FunctionalTestFreeStyle job fails, capistrano command is not executed and deploy is cancelled.