LogoLogo
Work with usToolboxPodcast
  • About this Handbook
  • Our organization
    • 📖History
    • 🏛️Constitution & Governance
      • 📜Articles of Association
      • 🎆Regional nodes & entities
    • 💟Our Values & Principles
    • 🗣️Partners and Associates
  • Agreements
    • People Agreement
    • Decision Agreement
      • Decision process for new GT courses
    • Financial Agreement
  • Working Together
    • 🥁Rhythms & Rituals
    • 💬Communication Practices & Tools
    • 📈Sales process & team formation
    • 🌱Development Bucket
    • 💸Biz Dev Bucket
    • 💚Spirit Bucket
  • Guides
    • ⛴️On & offboarding
    • 😎Setting up projects
    • 💰Finance - Overview
    • 📎Everything you need to know about invoicing
    • 👥How to use our CRM
    • 🎪Attending Events
  • Projects
    • Cobudget
      • Development
      • Deployment
      • Email
    • Greaterthan Academy
  • Archive
    • 💬Organizational tools
Powered by GitBook
LogoLogo

What we do

  • Services
  • Academy
  • Events

Connect

  • Email us
  • Find a coach
  • Join our newsletter

This work is licensed under Creative Commons Attribution-ShareAlike

On this page
  • Frontend Deployment Pipeline
  • Deploy Process
  • Rollbacks
  • Backend Deployment Pipeline
  • Database and backups
  • Deploy Process
  • Rollbacks
  • Timing: backend and frontend
Edit on GitHub
Export as PDF
  1. Projects
  2. Cobudget

Deployment

Last updated 7 years ago

Frontend Deployment Pipeline

The app frontend is developed in the repo and is hosted using . This is done by building the app locally into a build directory, and then pushing that build directory to a separate, dedicated production (or staging) repo ( and , respectively).

package.json has scripts for stage and deploy which uses a tool called to publish the build directory to a specific remote (staging or production). it creates a new repo inside the build dir, and then deploys that to the gh-pages branch of the staging/remote repo.

  • note: i'm not totally clear how npm run deploy-push knows to only push the contents of the build directory, since it appears to be running at the primary repo level.

  • There is a > 2 year old travis instance for the cobudget-ui repo, so I guess this has not been getting used.

Deploy Process

  1. submit a pull request to master

  2. have someone else merge it and delete the branch

  3. pull down master locally: git pull origin master

  4. make sure remotes are set: npm run set-remote-stage or npm run set-remote as appropriate

  5. to push to : npm run stage

  6. to push to : npm run deploy

  7. reset $NODE_ENV=development after deploy so that the repo looks for the right backend URL (localhost).

Rollbacks

  1. on production: git reset HEAD~1

  2. fix the bug locally

  3. Push the fixes

  4. run npm run deploy again, which will push the new changes and update HEAD past the broken commit to the new one.

Backend Deployment Pipeline

  • Heroku config...

  • There is currently no staging server for the api.

  • There is an active travis instance for the cobudget-api repo.

Database and backups

  • Database is Postgres

  • Database is scheduled to be backed up daily. You can check backup schedules with heroku pg:backups:schedules.

  • View the latest backups by following the link to the database from the heroku dashboard, or using the CLI.

Deploy Process

  1. make sure tests pass locally: run rspec

  2. submit a pull request to master

  3. ensure travis tests have passed

  4. have someone else merge it and delete the branch

  5. pull down master locally: git pull origin master

  6. git push heroku master

  7. heroku run rake db:migrate if necessary.

Rollbacks

  • roll back to the previous commit: heroku rollback

  • roll back to the previous DB version if necessary: heroku run rake db:rollback STEP=1 (or however many steps are appropriate).

Timing: backend and frontend

  • Use an appropriate ordering between frontend and backend when deploying changes to both repos. Usually, deploy backend first.

The app backend is developed in the repo and is hosted on heroku.

More on downloading and restoring from backup .

Heroku has a command. Rolling back on Heroku will only 'reactivate' a previous commit, it won't actually change the repository on Heroku. So if you were to then pull and push your Heroku remote (which should usually do nothing), you'll actually redeploy the commit that you rolled back.). Rollback also does not update the database or rollback migrations, so this has to be done manually.

cobudget-ui
github pages
cobudget.co
staging.cobudget.co
gulp-build-branch
staging
production
reset head
cobudget-api
here
rollback