1 00:00:00,016 --> 00:00:04,710 For any non-trivial application, the process of implementing a new feature or 2 00:00:04,710 --> 00:00:09,330 a bug fix should follow a well defined development, testing, and 3 00:00:09,330 --> 00:00:10,930 deployment workflow. 4 00:00:10,930 --> 00:00:13,660 This is especially true for any features or 5 00:00:13,660 --> 00:00:18,837 bug fixes that require changes to your applications in a data model. 6 00:00:18,837 --> 00:00:24,240 A migration that contains a bug can result in extended application downtime 7 00:00:24,240 --> 00:00:28,180 while users wait for data to be recovered from backups. 8 00:00:28,180 --> 00:00:31,290 Let's look at a high level overview of a typical workflow. 9 00:00:32,520 --> 00:00:36,600 A new feature or a bug, often referred to as an issue or task, 10 00:00:36,600 --> 00:00:39,806 is assigned to a developer to implement or fix. 11 00:00:39,806 --> 00:00:44,206 The developer uses their local development environment to resolve the issue or 12 00:00:44,206 --> 00:00:46,080 complete the task. 13 00:00:46,080 --> 00:00:50,775 Once the developer has developed and tested their changes, they commit and 14 00:00:50,775 --> 00:00:55,040 sync those changes to a central source code repository. 15 00:00:55,040 --> 00:01:01,410 The application is then built and deployed to a shared environment known as dev. 16 00:01:01,410 --> 00:01:04,590 the point changes to a shared environment makes it easy for 17 00:01:04,590 --> 00:01:09,090 anyone on the development team to review and test changes. 18 00:01:09,090 --> 00:01:12,720 It's not every team member may have a local development environment 19 00:01:12,720 --> 00:01:13,430 available to them. 20 00:01:14,550 --> 00:01:19,000 The dev environments database typically contains a mixture of test and 21 00:01:19,000 --> 00:01:20,430 production data. 22 00:01:20,430 --> 00:01:25,120 Test data makes it easier to test specific scenarios within the application. 23 00:01:25,120 --> 00:01:30,140 While production data allows you to test the application under conditions that 24 00:01:30,140 --> 00:01:32,910 closely mirror the production environment. 25 00:01:32,910 --> 00:01:36,190 The dev environment often has additional or 26 00:01:36,190 --> 00:01:41,590 verbose logging enabled in order to help developers debug exceptions and errors. 27 00:01:42,760 --> 00:01:47,050 Once the development team is satisfied that the changes are working properly, 28 00:01:47,050 --> 00:01:49,400 the application is then built and 29 00:01:49,400 --> 00:01:53,770 deployed to another shared environment known as test. 30 00:01:53,770 --> 00:01:57,050 While the dev environment is often only accessible to members 31 00:01:57,050 --> 00:01:58,520 of the development team. 32 00:01:58,520 --> 00:02:02,360 The test environment is typically accessible to people outside of 33 00:02:02,360 --> 00:02:08,860 the development team such as QA testers, key users, or business stakeholders. 34 00:02:09,900 --> 00:02:12,900 The test environments database typically contains 35 00:02:12,900 --> 00:02:15,310 a recent version of the production data 36 00:02:15,310 --> 00:02:20,010 in order to simulate the production environment as closely as possible. 37 00:02:20,010 --> 00:02:24,460 Test data may or may not be available depending on your specific situation. 38 00:02:25,790 --> 00:02:29,233 Once everyone that is responsible for testing the application, 39 00:02:29,233 --> 00:02:33,436 in the test environment, is satisfied that the changes are working properly. 40 00:02:33,436 --> 00:02:40,809 The application is then built and deployed to the production or prod environment. 41 00:02:40,809 --> 00:02:44,996 The prod environment including all of the application code and 42 00:02:44,996 --> 00:02:50,290 database is typically backed up right before a deployment is done. 43 00:02:50,290 --> 00:02:55,080 This allows for the previous version of the application to be quickly restored, 44 00:02:55,080 --> 00:02:56,250 in case something goes wrong. 45 00:02:57,400 --> 00:02:59,720 There are many variations of this workflow. 46 00:02:59,720 --> 00:03:03,690 The most workflows have some semblance of the three types of environments, 47 00:03:03,690 --> 00:03:06,630 dev, test, and prod. 48 00:03:06,630 --> 00:03:10,130 Most development teams will strive to automate as many parts of their workflow 49 00:03:10,130 --> 00:03:15,570 as possible, in order to reduce the overhead of manual builds and deployments. 50 00:03:15,570 --> 00:03:20,560 Automation also helps ensure predictable results as automated scripts 51 00:03:20,560 --> 00:03:24,920 are less likely to make a mistake when building and deploying the application. 52 00:03:26,020 --> 00:03:29,994 Managing and automating a workflow is a non-trivial task. 53 00:03:29,994 --> 00:03:34,508 Given that, most teams have evolved to include a role that is responsible for 54 00:03:34,508 --> 00:03:38,259 defining, creating, and testing your applications built and 55 00:03:38,259 --> 00:03:40,260 deployment processes. 56 00:03:40,260 --> 00:03:44,630 The people who fill that role are often referred to as dev ops or 57 00:03:44,630 --> 00:03:47,350 system reliability engineers. 58 00:03:47,350 --> 00:03:51,460 Regardless of your specific development, testing and, deployment workflow, you'll 59 00:03:51,460 --> 00:03:56,610 need a way to apply Pinney migrations to databases hosted in shared environments. 60 00:03:56,610 --> 00:04:00,510 Next, we'll review the deployment options that could first migrations 61 00:04:00,510 --> 00:04:01,510 makes available to us.