Information Technology Reference
In-Depth Information
Deployments are doneinoneofat least twoenvironments: the test environment andthe
live production environment. The service is created initially in the test environment, which
isnotexposedtocustomers.Inthisenvironment,aseriesoftestsarerunagainsttherelease.
When a release passes these tests, it becomes a release candidate. A release candidate is a
version with the potential to be a final product—that is, one that is deployed in production
for customer use.
The software may be deployed in other environments, such as a
private sand-box
en-
vironment where the engineering team conducts experiments too disruptive to attempt in
the test environment. Individual developers should each have at least one private envir-
onment for their own development needs. These environments are generally scaled-down
versions ofthe largersystem andmay even runonthe developers' ownlaptops. There may
beotherseparate environments forotherreasons.Forexample, theremaybeademoenvir-
onment used to give previews of new releases to stakeholders. Alternatively, new releases
maybedeployedinanintermediateproductionenvironmentusedby“earlyaccesscustom-
ers” before they are deployed into the main production environment.
At a minimum, every site must have separate testing and production environments,
where the testing environment is built exactly like production. Developers' own environ-
mentsaretypicallylesswellcontrolled,andtestinginsuchanenvironmentmaymisssome
issues. It is negligent to move a release straight from developer testing into production, or
to not have an environment for testing the configuration management systems. There is no
good reason to not invest in the additional infrastructure for a proper test environment—it
always pays for itself in increased service availability.
Whileonemaythinkofthebuildphaseasthedomainofdevelopersandthedeployment
phase as the domain of operations, this is not true in a DevOps environment. Both groups
share responsibility for the construction and use of the entire system. The handoff between
steps marks the flow of work, not organizational boundaries.
9.1.2 Anti-pattern: Waterfall Methodology
The waterfall methodology works differently from the modern DevOps methodology. It is
predicated on multiple phases, each controlled by a different organization. Handoffs not
only mark the flow of work, but also indicate the end of each organization's responsibility.
The waterfall methodology was previously discussed in
Section 8.1.1
.
The waterfall methodology has many phases. The first phase is controlled by the devel-
opment organization, which has two teams: software engineers (SWEs) and quality assur-
ance (QA) engineers. The SWEs create the source code, which they compile and package.
The QA team tests the packages in its own environment. When the team approves the soft-
ware, it is designated as a release candidate and passed to the next phase. The next phase is
Search WWH ::
Custom Search