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.