Workflows and Environments

For any non-trivial application, the process of implementing a new feature or 0:00 a bug fix should follow a well defined development, testing, and 0:04 deployment workflow. 0:09 This is especially true for any features or 0:10 bug fixes that require changes to your applications in a data model. 0:13 A migration that contains a bug can result in extended application downtime 0:18 while users wait for data to be recovered from backups. 0:24 Let's look at a high level overview of a typical workflow. 0:28 A new feature or a bug, often referred to as an issue or task, 0:32 is assigned to a developer to implement or fix. 0:36 The developer uses their local development environment to resolve the issue or 0:39 complete the task. 0:44 Once the developer has developed and tested their changes, they commit and 0:46 sync those changes to a central source code repository. 0:50 The application is then built and deployed to a shared environment known as dev. 0:55 the point changes to a shared environment makes it easy for 1:01 anyone on the development team to review and test changes. 1:04 It's not every team member may have a local development environment 1:09 available to them. 1:12 The dev environments database typically contains a mixture of test and 1:14 production data. 1:19 Test data makes it easier to test specific scenarios within the application. 1:20 While production data allows you to test the application under conditions that 1:25 closely mirror the production environment. 1:30 The dev environment often has additional or 1:32 verbose logging enabled in order to help developers debug exceptions and errors. 1:36 Once the development team is satisfied that the changes are working properly, 1:42 the application is then built and 1:47 deployed to another shared environment known as test. 1:49 While the dev environment is often only accessible to members 1:53 of the development team. 1:57 The test environment is typically accessible to people outside of 1:58 the development team such as QA testers, key users, or business stakeholders. 2:02 The test environments database typically contains 2:09 a recent version of the production data 2:12 in order to simulate the production environment as closely as possible. 2:15 Test data may or may not be available depending on your specific situation. 2:20 Once everyone that is responsible for testing the application, 2:25 in the test environment, is satisfied that the changes are working properly. 2:29 The application is then built and deployed to the production or prod environment. 2:33 The prod environment including all of the application code and 2:40 database is typically backed up right before a deployment is done. 2:44 This allows for the previous version of the application to be quickly restored, 2:50 in case something goes wrong. 2:55 There are many variations of this workflow. 2:57 The most workflows have some semblance of the three types of environments, 2:59 dev, test, and prod. 3:03 Most development teams will strive to automate as many parts of their workflow 3:06 as possible, in order to reduce the overhead of manual builds and deployments. 3:10 Automation also helps ensure predictable results as automated scripts 3:15 are less likely to make a mistake when building and deploying the application. 3:20 Managing and automating a workflow is a non-trivial task. 3:26 Given that, most teams have evolved to include a role that is responsible for 3:29 defining, creating, and testing your applications built and 3:34 deployment processes. 3:38 The people who fill that role are often referred to as dev ops or 3:40 system reliability engineers. 3:44 Regardless of your specific development, testing and, deployment workflow, you'll 3:47 need a way to apply Pinney migrations to databases hosted in shared environments. 3:51 Next, we'll review the deployment options that could first migrations 3:56 makes available to us. 4:00