Deployment

To support deployment without requiring you to enter a credit card or running into limits on team sizes, etc. we have our own simple cloud deployment platform csci312.dev. In short, you will push your code to a deployment repository at csci312.dev, which will then build and deploy your application at https://<project name>.csci312.dev, e.g, https://simplepedia.csci312.dev.

1. As a prerequisite, you should have added an SSH key to GitHub as described in the getting started instructions. Doing so is necessary to obtain deploy permissions. If you attempt the below and get permission-related errors, contact the instructor to make sure your key has been added to the deployment server.
2. Add the deployment repository as a remote in your repository: 💻 git remote add deploy git@csci312.dev:<project name>, e.g., 💻 git remote add deploy git@csci312.dev:simplepedia. Note that <project name> is the name assigned to your group, e.g., “mansfield”.
3. Push the main branch to the deploy repository: 💻 git push deploy main. This should automatically build and deploy your application at https://<project name>.csci312.dev. Any errors should hopefully be reported on in the terminal as the push proceeds.
4. To add entries to the .env.local file on csci312.dev, execute 💻 ssh git@csci312.dev secrets <project name> KEY=value, where again <project name> is the name assigned to your group. KEY=value is the value you want to add or update in the file (without any spaces). For example, 💻 ssh git@csci312.dev secrets simplepedia NEXTAUTH_URL=https://simplepedia.csci312.dev would set the NEXTAUTH_URL key for the simplepedia project. If your value has special characters, like the ‘?’ in some database URLs, you may need to surround the KEY=value with single quotes, e.g., 'KEY=value', so that your shell doesn’t try to interpret the special characters for its own purposes. If you don’t provide a KEY=value argument, e.g., 💻 ssh git@csci312.dev secrets simplepedia, the secrets command will print out the current secrets.
5. To view the most recent logs from your application execute 💻 ssh git@csci312.dev logs <project name>. You can optionally add a --lines argument, e.g., --lines 50 to look at more lines.
6. Typically a new deployment will also involve changes to your database schema and or seeding. If you are using the RDBMS configuration from the practical you can migrate and seed the production database from your local computer by setting the node environment to production before your knex commands, e.g., on OSX/Linux or if you are using BASH on Windows (less common):

    💻 NODE_ENV=production pnpm exec knex migrate:latest
    💻 NODE_ENV=production pnpm exec knex seed:run
   

   For Windows (and to create scripts that can be used across platforms) I recommend installing the cross-env package (💻 pnpm install -g cross-env installs it globally, independent of any particular project). You can use cross-env to specify environment variables in a platform-independent way. Specifically the commands above would be implemented as

    💻 cross-env NODE_ENV=production pnpm exec knex migrate:latest
    💻 cross-env NODE_ENV=production pnpm exec knex seed:run
   

I encourage you to test the production version of your application locally before deploying to the server. You can do with:

💻 pnpm run build
💻 pnpm run start

This will build the production version of your application and start if the same way as the server (e.g., setting the production environment so you use the production database). If this doesn’t work locally, it is unlikely to work remotely!