Transforming Teaching with Teachingo - Update #3
Tags: twiliohackathon, node, react, javascript
Published: 2020-04-19 15:35:17

_This is an update on our #TwilioHackathon project progress - you can see the original post here: {% link https://dev.to/chloemcateer3/transforming-teaching-with-teachingo-4lc5 %}_

---

## Deploy, deploy, deploy! 🚀

Ultimately, whenever we're building out side projects and hackathons, we like to get our code deployed somewhere so that we don't have to worry about having to spin the services up locally for a demo etc.

It also pushes us out of our comfort zones as it makes us think about infrastructure, different tooling and approaches of how we can ship our code!

Since we were developing two services independently (web application & backend API), we wanted to deploy them independently. This meant that we could work on both of them in isolation without having to worry about the state of the other one, which is pretty critical when it comes to deploying to production.

### Backend API 🧠

With our backend consisting of a Node.js service, we wanted to keep the deployment fairly straightforward. Both of us have pretty good knowledge of [Heroku]() and have built some projects with the platform before.

We also knew that it could handle spinning up a database instance and made connecting to it from the Heroku application super simple.

Spinning up a quick Heroku application from the CLI is easy and within minutes we had our code deployed. One of the other great benefits of Heroku is the many integration points it has with other services, for example: GitHub.

We were able to configure the application to point at the backend GitHub repoistory and setup automatic deployments whenever a commit is merged into master.

Finally, we were able to provision a new PostgreSQL database instance via the Heroku CLI again and with some easy Knex integrations, we had it deployed!

![Brooklyn Nine Nine, Amy saying everything](https://media.giphy.com/media/l3vR20N0ztCmPL0oU/giphy.gif)

### Web Application 💥

We aren't doing anything special with the web application (e.g. server-side rendering), so we just want to serve the static assets to the client.

Sure, we could have utilised the backend API server to actually serve the static assets but this would introduce unnecessary overhead in its build process, ultimately coupling the deployment for both services - which is the main thing we're trying to avoid.

With so many platforms and services available now, we decided to go with [Netlify](https://www.netlify.com/) as it comes with some super nice integrations and handles everything out of the box for us.

Pointed it at the GitHub repository, setup the build command and automatic deploys whenever a commit has been pushed to master (always from a PR 😉) and that's it! Super simple setup, within minutes we had our client deployed and hosted on the Netlify CDN.

![Brooklyn Nine Nine, Diaz smiling!](https://media.giphy.com/media/TjqEcu16wZDibt0GyU/giphy.gif)

## Automate all the things 🤖

With both Heroku and Netlify handling automatic deployments for us, we wanted to complete the puzzle by adding some form of CI/CD pipeline - just to make sure we weren't merging bad code.

Again, we opted for the simplest option of GitHub Actions - this allowed us to create pipelines for both repositories that were invoked whenever we submitted PRs to them.

We weren't doing anything crazy, just simply running our unit tests and reporting the status back to the PR, easy!

---

Stay tuned for more progress updates from [Chloe](https://dev.to/chloemcateer3) and myself!