Caffeine Driven Software Engineer

Migrating a schema when deploying code is a fairly solved problem in Rails, and many other languages/frameworks. What hasn't quite been solved, or at least agreed upon, is the ability to make changes to data based on those migrations. I'm not going to cover the dos, donts, pros and cons of each method as many people before me have covered this in great detail. What I do want to do however, is share a nice simple solution I created for simplifying this process, and making the most out of previous methods.

Although what I'm about to talk about is well documented[1], I've never come across it in my 10 year career using Git. I stumbled across it out of sheer curiosity to see what would happen if I used a repository instead of a remote name. In theory Git would treat them the same, since everything is technically a ref, and it did. The idea is simply to be able to push your code anywhere, without having to first add the remote to your local repository. You're probably asking why you would want to do this, or why anyone would even care that this is possible. I have a few use cases below which are now way easier day to day.

A few weeks ago I decided to take the leap and implement Webpacker into an existing Rails project. Initially this seemed like a great idea and almost too easy thanks to the rails/webpacker project. After a couple of hours I had everything working and some existing React components migrated from a custom compile system to the asset pipeline. Deploying to staging had a few minor hiccups, but nothing major and the project was ready for sign-off and production release.

Time and time again I've found myself needing to limit access to S3 repositories via write-only. Read-Only access is widely used for public repositories, such as CDNs. A highly common use case for write-only access is allowing users to upload new files, but not modify any that currently exist.

I've lost count of the amount of times I've forgotten the syntax for creating users, databases and permissions within postgresql. After spending so many years working with MySQL it became muscle memory and for some reason I can't shake those commands. Unlike MySQL, which I used to host myself and understand the internals of security/performance, I've only ever used hosted versions of PostgreSQL where all of this is taken care of.