Sometimes new features require a migration

When parts of the platform substantially change, sometimes you need to perform a migration or reboot the application. Often that means that someone has to stay up till early morning to minimize the impact on users.

But this is slow, inconvenient and potentially dangerous

This approach makes the feature slower to deploy. It’s also very inconvenient.

I got caught out by that a few times. In particular, when making changes to product search, I had to re-index the products.

I’d have to redirect the app to a maintenance page till the index updates. Otherwise, there would be no results returned.

So, you should split your changes into the migration and the functionality

Instead, you should be aware that a change will require this type of work before starting it.

When you realize that might be the case, you should split the work into two parts.

The first part will only update the existing structure to the new one while preserving it.

The second part is going to implement the new functionality.

That way, when you deploy, you can push the structural changes first.

Then you can trigger any migrations that might be required. In the example previously, that was re-indexing products.

You can often do this even while the application still running. Both structures would work at the same time.

Once the feature is complete, you can deploy the updated functionality with no downtime.

You’ll be able to deploy quicker, and you’ll not have to deploy at an ungodly hour.