Single step deployment to development and production servers

Originally intended to publish the code for the updated website, but got carried away and worked on improving the workflow for pushing new builds to servers instead.

Continuing on the same concepts as I have written about before: Swift & direct development setup and Inspiring workflow. First about being able to code and see the changes in the running project instantly without leaving the editor and the second about working on assets and seeing changes in the running project without leaving the asset application.

The project template used in those above videos to make games, is the same template used to make the website. Doing the improvements to the workflow for the website means I can transfer the improvements to the games later.

My old workflow for making a new build was this:

1. Run the build script and get a new build in folder build/.
2. Use an extension for VSC called Deploy to execute configurations that would upload the files to a development S3 bucket on AWS.
3. If the development build performed as intended, using the S3 console to copy the files from development bucket to production bucket.
4. Go to the CloudFront interface to initiate an invalidation of the files. This makes sure no cached versions of old files are served on the distributed network.
5. Due to problems getting Deploy to automatically remove files in a way that worked for all situations, I had done two things: 1. Removed hash strings from files in order to overwrite files instead of having duplicate files with different hashes. 2. Using S3 console to manually delete files when needed.

Steps 1 and 2 would be most of the time. After running the local version for a while, you want to try it in the actual system and upload it to the development server. This was OK. Then the rest of the steps were fine in that they did not occur that often, but it did take a minute or two. Doing it manually also adds the possibility of doing an error!

The new workflow for deploying a build:

1. Run the build script and answer at most two questions.

If for development, answer the question if you want to push all files or only code files. If for production, answer the question if you have remembered to sync git and a final safety question if you are sure want to upload.

The script takes care of building, adding extra files, editing in differences in paths (if prod and dev have the project in different places, say one in root and the other in a sub-folder), cleaning the S3 bucket, uploading to it and if production invalidating the CloudFront distribution.

I implemented it like so:

• Adding a "project_settings" section to the package.json for the project. This contains buckets, cloudfronts, paths and additional files to add to a build.
• Writing a few short scripts and integrating them into suitable places in the preact.config.js file and using the new project_settings in those scripts.
• Being clever and using "npm install package X" for everything that would require a bit of time to code. Usually I would avoid using too many packages, as you would want the release to be as small as possible and with as little unknowns as possible. But here the code was only for development tasks, making it not as crucial. Great packages used are: glob, mime, aws-sdk, prompt-confirm, console-progress-bar and git-rev-sync.

I have a bug I want to fix before uploading to GitHub, but hopefully early next week. While the site might not be awesome as a whole, it has many shorter useful implementations of preact, bulma and S3 uploading.

Game development using web technologies.

Spelmakare.se
Discord
GitHub