Learn the steps involved in getting code from your computer out into the world and into the hands of users.

What is Deployment?

Branches, copies of the "trunk", can be worked on independently. When it is time, new code can be merged into the trunk.

_Gabriel is excited to get their code onto their company's servers. They sneak into the server room and pull out their USB stick. Right as they are about to plug it into the server, Lars stops him and says, "Whoa there Gabriel! That's not how we do things around here. You should check out our version control system."_

**Version control systems** (such as [Github](https://www.codecademy.com/learn/learn-git)) are tools designed to manage different versions of a file or project. They track every change that is made to a file while saving all previous versions of the file. Some of the data that is tracked by a version control system includes:

* changed files
* new or deleted files
* renamed or moved files
* the author and date of the change

With version control (a.k.a. "source control"), the risk and impact of bugs are reduced. When a new version of the software has issues, it can be compared to previous "stable" versions to identify the error. If necessary, the software can be "rolled back" to previous versions until a fix is implemented. With the author and date of each change stored, development teams can quickly identify who has the most information about a breaking change. 

Version control systems (VCS) change how teams work together. Common operations of version control, such as **branching** and **merging** enable development teams to collaborate more effectively.
* Branching is the process of creating a copy of the source code (the "trunk"). Developers can work on their own branches without changing the source code that real users and other developers depend on.
* Merging is the process of combining the changes in one branch with another. This occurs when the differences between the two branches are ready to be reconciled. When conflicts between branches arise during a merge, version control systems can assist in resolving them.

Lastly, version control systems are able to synchronize with project management tools. For example, when new code is added, an engineering manager can be alerted to review the changes.

Version Control Systems

Various pieces of hardware are connected with lines in a network/on a map. (Laptops, servers, data centers, smartphones, cloud)

_Gabriel is excited to learn about how their company's software is accessed by their users. They head over to see Lars, a member of the Operations team, who is setting up a server in the server warehouse._

In the modern age of web applications, software is stored and executed on **servers**. Servers are computers that run software that can be accessed by another device (also known as the **client**), often via the internet. Servers respond to requests with website code, images, and other content which are rendered by the client (typically a web browser).

Servers require quite a bit of maintenance in order to be used by developers. They need to be purchased, have operating systems and various software installed on them, configured to handle network requests, and much more. Typically, developers don't manage the servers — so who does?

Traditionally, an Operations team is responsible for managing a company's servers. More broadly, the Operations team manages all of an application's **infrastructure**. Infrastructure is the full set of resources that support the development, testing, and deployment of applications. Infrastructure consists of:

* Hardware components such as servers, routers, switches and cables
* Software components such as operating systems, version control systems, and applications

There are dozens of tasks that fall under the responsibility of the Operations team, including:
* Installing and replacing (a.k.a "provisioning") physical components such as servers, switches, and hard drives
* Performing software/firmware upgrades such as security patches
* Configuring infrastructure such as firewalls, user access, ports
* Monitoring network health and alerting personnel when issues arise


Infrastructure Management

The development environment is where code is first written, typically on developers' own laptops. The staging environment is where new software is tested before being deployed to production where users can access the application.

_Gabriel's new feature went from their own computer, into the version control system, passed tests, and was merged into the source code. Now, it's time to "deploy to production"! But what exactly does that mean?_

The **production environment** refers to the infrastructure that supports the complete application used by real users. This infrastructure consisted of hardware and software components scaled for real-world usage.

More broadly, an **environment** is the subset of infrastructure resources used to execute a program under specific constraints. 

Along the way to the production environment, software often moves through a series of intermediate environments. Each intermediate environment allows developers to rigorously test new software without impacting production infrastructure.

Though the names of environments may differ from company to company, a common set of environments includes:
* The **local development environment** — where software is first written and tested, typically on a developer's own computer.
* The **integration environment** — where software changes are merged using a version control system.
* The **quality assurance (QA) / testing environment** — where tests are executed to ensure the functionality and usability of each new feature.
* The **staging environment** — where the software can be performance tested in a production-like environment, but before real users are involved.
* The **production environment** — where software is accessible by real users!

These environments do not strictly represent a linear path from a developer's computer to production. Instead, each of these environments can be viewed as a space that developers can use throughout the entire deployment process. 

Deployment Environments

_Monica is Gabriel's engineering manager. Gabriel has checked their code into the version control system and wants users to access the new feature as soon as possible. Monica knows better. Changes need to be tested before being released to users._

**Testing** is an essential component of the deployment process. Testing ensures new features integrate with existing features, work smoothly within the existing infrastructure, and satisfy the product and design requirements. 

Different types of tests exist that are used in the various stages of deployment. Four types of tests that are often used are:
* **Unit test** — evaluates the smallest possible unit of testable code, such as a single function.
* **Integration test** — evaluates how the units of a particular program work with one another.
* **Acceptance test** — evaluates whether the user experience aligns with the business requirements of the software. 
* **End-to-end test** — evaluates the application's behavior using production-like infrastructure that includes networking, databases, and calls to external APIs. 

Failures during testing help developers know that they need to update their code or increase their infrastructure resources. Success during testing gives a developer confidence that their project is in a releasable state.

For example, a developer’s workflow might incorporate testing like so:
1. Develop a new feature locally
2. Add new code to the version control system
3. The code change has tests run against it (unit, integration, sometimes acceptance or end-to-end)
4. If there are any failures, the developer will work on fixes
5. Repeat steps 1-4 until all tests pass.
6. The change is allowed to be merged.

Testing

Code moves from a developers laptop through the deployment process. Along the way there is version control, testing, and various environments.

_Gabriel is a junior software developer who has just finished working on a new feature. They are excited to share their code with their users. What happens next? Do they go door to door installing it manually from a floppy disk? Maybe they can send the files via email! No — these aren't the stone ages!_

**Deployment** is the general process of making a piece of software available to its users. Before the invention of the internet, deployment meant storing software on floppy disks or CD-ROMs, shipping them to users, and having those users manually install the software on their own devices. This process  was slow and expensive, and any bugs that slipped through the cracks could be [catastrophic](https://en.wikipedia.org/wiki/Disney%27s_Animated_Storybook#Release_of_The_Lion_King_storybook_(November_1994)).

Today, software developers are able to deploy their software via the internet with greater ease and speed of delivery than ever before. The process for deployment is largely the same whether it is for the major release of a new application, or a minor patch to fix a bug.

In this lesson, we will discuss the various components that make up this deployment process. Though deployment is a general process that can include many different steps, we will cover the most commonly used tools and practices:

* Infrastructure management
* Version control systems
* Testing: unit, integration, acceptance, and end-to-end tests
* Deployment environments

Traditionally, members of the Development team and the Operations team take ownership of various aspects of the deployment process. We'll start by taking a look at the main responsibility of the Operations team, managing the infrastructure.


_Gabriel's new feature has finally been deployed to production! Users around the world are accessing the new feature via servers, networks, and other infrastructure. Their user experience is as good as ever thanks to extensive testing and version control._

In this lesson, we learned about **deployment** — the process of making a piece of software available to its users. Deployment is a long journey that starts with a developer moving their code into a **version control system**, through a **staging environment**, and ends with them deploying their code to a **production environment**. Along the way, **unit**, **integration**, **end-to-end**, and **acceptance tests** are conducted. 

This deployment process ensures that new code is shipped quickly, reliably, and with high quality. Members of the Development team and Operations team own various pieces of this process. In the next lesson on DevOps culture, you will learn how the boundaries between these two teams begin to blur in order to create a more open, and efficient, team dynamic.