Heads up! To view this whole video, sign in with your Courses account or enroll in your free 7-day trial. Sign In Enroll
Preview
Start a free Courses trial
to watch this video
The process of implementing a new feature or bug fix should follow a well-defined development, testing, and deployment workflow. Let's look at a high level overview of a typical workflow.
Additional Learning
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
You need to sign up for Treehouse in order to download course files.
Sign up