For any non-trivial application, the process of implementing a new feature or

a bug fix should follow a well defined development, testing, and

deployment workflow.

This is especially true for any features or

bug fixes that require changes to your applications in a data model.

A migration that contains a bug can result in extended application downtime

while users wait for data to be recovered from backups.

Let's look at a high level overview of a typical workflow.

A new feature or a bug, often referred to as an issue or task,

is assigned to a developer to implement or fix.

The developer uses their local development environment to resolve the issue or

complete the task.

Once the developer has developed and tested their changes, they commit and

sync those changes to a central source code repository.

The application is then built and deployed to a shared environment known as dev.

the point changes to a shared environment makes it easy for

anyone on the development team to review and test changes.

It's not every team member may have a local development environment

available to them.

The dev environments database typically contains a mixture of test and

production data.

Test data makes it easier to test specific scenarios within the application.

While production data allows you to test the application under conditions that

closely mirror the production environment.

The dev environment often has additional or

verbose logging enabled in order to help developers debug exceptions and errors.

Once the development team is satisfied that the changes are working properly,

the application is then built and

deployed to another shared environment known as test.

While the dev environment is often only accessible to members

of the development team.

The test environment is typically accessible to people outside of

the development team such as QA testers, key users, or business stakeholders.

The test environments database typically contains

a recent version of the production data

in order to simulate the production environment as closely as possible.

Test data may or may not be available depending on your specific situation.

Once everyone that is responsible for testing the application,

in the test environment, is satisfied that the changes are working properly.

The application is then built and deployed to the production or prod environment.

The prod environment including all of the application code and

database is typically backed up right before a deployment is done.

This allows for the previous version of the application to be quickly restored,

in case something goes wrong.

There are many variations of this workflow.

The most workflows have some semblance of the three types of environments,

dev, test, and prod.

Most development teams will strive to automate as many parts of their workflow

as possible, in order to reduce the overhead of manual builds and deployments.

Automation also helps ensure predictable results as automated scripts

are less likely to make a mistake when building and deploying the application.

Managing and automating a workflow is a non-trivial task.

Given that, most teams have evolved to include a role that is responsible for

defining, creating, and testing your applications built and

deployment processes.

The people who fill that role are often referred to as dev ops or

system reliability engineers.

Regardless of your specific development, testing and, deployment workflow, you'll

need a way to apply Pinney migrations to databases hosted in shared environments.

Next, we'll review the deployment options that could first migrations

makes available to us.