Deployment, Cloud and DevOps Foundations

Introduction

Deployment is the process of making a software application available for use in a target environment. In full-stack development, deployment includes much more than copying files to a server. It involves building the application, managing dependencies, configuring services, connecting databases, securing communication, monitoring operation, and providing a reliable method for releasing changes.

DevOps is a set of practices and cultural principles that bring software development and operations closer together. Its central purpose is to shorten the path from a validated code change to a reliable production service while maintaining quality, security, and operational control. Cloud computing provides elastic infrastructure and managed services that can support these practices, but cloud adoption alone does not constitute DevOps.

A typical deployment pipeline transforms source code into a running service:

Source code → Build → Automated tests → Package → Deploy to staging → Approval or automated promotion → Production → Monitoring

This chapter introduces the practical foundations required to package and deploy full-stack applications. It explains CI/CD, containers, cloud service models, configuration, domains, TLS, databases, backups, scaling, observability, and infrastructure cost.

Learning Objectives

By the end of this chapter, you should be able to:

1. Explain the purpose and stages of a CI/CD pipeline.
2. Package an application using a reproducible build and container image.
3. Distinguish virtual machines, containers, serverless services, and managed cloud services.
4. Separate configuration and secrets from application code.
5. Connect a domain securely using DNS and TLS.
6. Plan database deployment, backup, recovery, and migration practices.
7. Select basic scaling strategies and interpret important operational metrics.
8. Estimate cloud cost and identify practical controls for reducing waste.
9. Apply deployment, security, governance, and rollback principles to a realistic application.

1. Deployment as an Engineering Process

A production system has several environments, each serving a different purpose.

Environment separation reduces the risk that unfinished work will affect users. However, environments should not become completely different systems. The closer staging resembles production, the more useful its results are. Differences that cannot be avoided should be documented.

A deployment unit may contain a frontend, backend API, worker processes, static assets, and a database. These components have different release and scaling requirements. For example, a frontend may be served from a content delivery network, while an API runs in containers and a database is provided as a managed service.

A release is the version of software made available to users. A deployment is the technical act of installing or activating that release. These terms are related but not identical: a release may be deployed gradually, and the same release may be deployed to several regions.

2. Continuous Integration and Continuous Delivery

2.1 Continuous integration

Continuous integration (CI) means that developers integrate changes frequently into a shared repository and use automated checks to detect defects. A CI job commonly performs the following tasks:

• checks out the source code;
• installs locked dependencies;
• performs formatting and static analysis;
• runs unit and integration tests;
• builds the frontend and backend;
• scans dependencies and images for known vulnerabilities;
• stores build artifacts or produces a container image.

CI is effective only when tests are trustworthy and feedback is rapid. A pipeline that takes hours or produces frequent false failures encourages developers to bypass it.

2.2 Continuous delivery and deployment

Continuous delivery means that every change that passes the pipeline is kept in a deployable state. Production release may still require a person to approve it. Continuous deployment goes further: qualifying changes are automatically released to production.

A responsible pipeline normally includes:

1. Source control trigger: a commit or pull request starts the workflow.
2. Validation: code quality, tests, security checks, and dependency checks run.
3. Build: a versioned artifact is created.
4. Staging deployment: the artifact is deployed to a production-like environment.
5. Verification: smoke tests and health checks confirm that the service responds.
6. Promotion: the same artifact is promoted to production rather than rebuilt differently.
7. Observation: logs, metrics, and alerts are reviewed.
8. Rollback: an earlier known-good version can be restored.

Building once and promoting the same artifact improves reproducibility. Rebuilding separately for staging and production can produce different dependency resolution, compiler output, or configuration behavior.

2.3 Deployment strategies

A rolling deployment replaces instances gradually. It is economical but may temporarily run old and new versions together. A blue-green deployment maintains two production environments: traffic is switched from blue to green after verification. It supports fast rollback but requires additional capacity. A canary deployment sends a small percentage of traffic to the new version before wider release. It reduces exposure but requires traffic control and meaningful monitoring.

Feature flags allow functionality to be enabled independently of code deployment. They are useful for gradual release, but unused flags create complexity and should be removed.

3. Packaging Applications with Containers

A container packages an application and its user-space dependencies into an isolated process environment. Containers share the host operating system kernel, unlike virtual machines, which generally include a complete guest operating system. Containers are therefore usually faster to start and more resource-efficient, although they do not provide an absolute security boundary.

Important container concepts include:

• Image: an immutable package containing application files, runtime components, and metadata.
• Container: a running instance of an image.
• Registry: a repository for storing and distributing images.
• Dockerfile or build definition: instructions for creating an image.
• Tag or digest: an identifier for an image version. A cryptographic digest is more immutable than a mutable tag such as latest.

A good image is small, reproducible, and contains only what is required at runtime. Multi-stage builds compile the application in one stage and copy only the compiled output into a smaller runtime stage. The process should run as a non-root user where possible, define a clear startup command, and write logs to standard output rather than depending on local log files.

Containers should be treated as replaceable. Persistent data should be stored in a database, object storage service, or managed volume rather than inside the writable layer of a container. If a container is deleted, its ephemeral filesystem may disappear.

A simplified build process is:

Application source → Dependency installation → Compilation/build → Runtime image → Registry → Deployment platform

Container orchestration becomes useful when multiple services must be scheduled, restarted, discovered, scaled, and updated. Platforms range from simple managed container services to complex orchestration systems. For a certificate-level project, a managed container platform is often preferable to operating a cluster manually.

4. Cloud Computing Models

Cloud services provide computing resources over a network, generally with usage-based pricing and provider-managed infrastructure. The major service models are:

Cloud responsibility is shared. A provider may secure the physical data centre and managed service platform, while the customer remains responsible for identity permissions, application vulnerabilities, data classification, and correct configuration. The exact division varies by service.

Cloud architecture commonly includes:

• compute for application processes;
• object storage for files and static assets;
• a relational or NoSQL database;
• a load balancer or API gateway;
• a private network and firewall rules;
• identity and access management;
• monitoring, logging, and alerting.

Managed services reduce operational effort, but they can create provider dependency, regional limitations, and unexpected costs. Service selection should consider reliability, data location, portability, performance, and total cost rather than convenience alone.

5. Configuration, Secrets, and Environments

Application code should not contain environment-specific values such as database addresses, API keys, passwords, or production domains. Configuration should be supplied through environment variables, configuration files managed outside the source repository, or a dedicated secrets manager.

A useful distinction is:

• Configuration: non-secret behavior, such as a port number or feature setting.
• Secret: information whose disclosure could enable unauthorized access, such as a password, private key, or access token.

Secrets should be encrypted at rest, restricted by role, rotated periodically, and excluded from source control and ordinary logs. A secret manager can provide controlled access, auditing, and rotation. Environment variables are convenient but are not automatically secure; access to the running process or deployment platform may expose them.

Configuration should be validated at startup. If a production database URL is missing, the application should fail clearly rather than start in a partially functioning state. Different environments may have different values, but the application should retain the same general behavior and interface.

The twelve-factor approach to application design recommends, among other principles, storing configuration in the environment, treating logs as event streams, keeping processes stateless, and separating build, release, and run stages. These ideas are useful guidelines, not a substitute for architectural judgment.

6. Domains, DNS, and TLS

A domain name is a human-readable name mapped to network services through the Domain Name System (DNS). Common DNS records include:

DNS changes are cached according to their time to live (TTL). Consequently, changes may not be visible everywhere immediately. A CNAME cannot normally be used at the root of a domain in the same way as for a subdomain, although DNS providers may offer an alias feature.

TLS encrypts traffic and authenticates the server through a certificate issued by a trusted certificate authority. HTTPS is HTTP carried over TLS. A typical secure setup points the domain to a load balancer or hosting service, obtains a certificate, redirects HTTP to HTTPS, and renews the certificate automatically.

TLS does not make an application safe by itself. Developers must still protect sessions, validate input, authorize actions, use secure cookies where appropriate, and avoid exposing sensitive data in URLs or logs. Certificate expiration, incorrect DNS records, mixed content, and incomplete certificate chains are common operational failures.

7. Database Deployment and Data Protection

Application deployment and database deployment must be coordinated. A schema migration changes tables, columns, indexes, constraints, or data. Migrations should be versioned, reviewed, tested, and applied in a controlled order.

A safe migration often follows an expand-and-contract pattern:

1. Add a new nullable column or compatible structure.
2. Deploy application code that can use both old and new structures.
3. Backfill or transform data in controlled batches.
4. Switch reads and writes to the new structure.
5. Remove the obsolete structure only after it is no longer needed.

This pattern reduces downtime and supports rolling deployments. A migration that immediately renames or removes a field may break old application instances still serving traffic.

A backup is a recoverable copy of data. Important backup concepts include:

• Recovery point objective (RPO): the maximum acceptable amount of data loss measured in time.
• Recovery time objective (RTO): the maximum acceptable time to restore service.
• Retention: how long backups are kept.
• Restore test: evidence that backups can actually be recovered.

If an organization can tolerate losing at most 15 minutes of data, its backup and replication design must provide an RPO of 15 minutes or less. A backup that is never restored in testing is an unverified assumption. Backups should be encrypted, access-controlled, geographically or logically separated from the primary system, and protected against accidental deletion or ransomware where appropriate.

The common “3-2-1” principle recommends maintaining at least three copies of data, on two different types of storage or media, with at least one copy off-site. It is a practical resilience guideline rather than a guarantee of recovery.

8. Scaling and Reliability Foundations

Vertical scaling increases the resources of one instance, such as CPU or memory. Horizontal scaling adds instances and distributes work among them. Horizontal scaling usually requires stateless application processes, shared session storage, externalized files, and a load balancer.

A service may scale based on CPU utilization, memory usage, request count, queue depth, or response latency. The selected metric should represent the actual bottleneck. Increasing instances cannot solve a database lock, inefficient query, external API limit, or network bottleneck.

A useful capacity relationship is based on Little’s Law:

Here, L is the average number of items in a stable system, λ is the average arrival rate in requests per second, and W is the average time an item spends in the system in seconds. The units are consistent because requests/second multiplied by seconds gives requests. The relationship assumes a stable long-run system and is useful for reasoning about queues and concurrency; it is not a complete performance model.

For example, if an API receives 20 requests per second and the average response time is 0.5 seconds, the average number of in-flight requests is:

This does not mean exactly ten requests exist at every moment; it is a long-run average.

Reliability engineering also uses availability. A simplified availability estimate is:

Both uptime and downtime must use the same time unit. This measure assumes the observation period is defined and that downtime is measured consistently. A target of 99.9% availability permits approximately 0.1% unavailability during the measurement period; for a 30-day month of 43,200 minutes, that is about 43.2 minutes. Availability targets should be tied to business impact rather than selected as marketing claims.

Health checks should distinguish liveness—whether a process should be restarted—from readiness—whether it can receive traffic. A process may be alive but not ready because its database connection is unavailable.

Observability combines:

• Logs: detailed event records;
• Metrics: numerical time-series measurements;
• Traces: paths of requests across services.

Alerts should identify actionable conditions, have an owner, and avoid excessive noise. Monitoring must not collect sensitive information unnecessarily.

9. Infrastructure Cost Fundamentals

Cloud cost is usually driven by resource quantity, duration, requests, storage, data transfer, and premium service features. A simplified estimate is:

The sum is taken across billable components, and units must match the provider’s pricing model. This is an estimate, not an invoice, because taxes, discounts, minimum commitments, tiered pricing, and regional differences may apply.

For example, if compute costs £0.04 per instance-hour and a project runs two instances for 10 hours, compute cost is:

Storage, database, requests, backups, and network transfer must be added separately.

Cost controls include rightsizing instances, shutting down non-production resources, applying budgets and alerts, using lifecycle rules for old objects, removing unused disks and addresses, selecting appropriate database capacity, and reviewing data-transfer patterns. The cheapest design is not always the best design: reducing backups or monitoring may lower the bill while increasing operational risk.

10. Security, Governance, and Operational Practice

Deployment security should follow least privilege: each user, service, and pipeline receives only the permissions required for its task. Multi-factor authentication, short-lived credentials, protected branches, code review, dependency updates, vulnerability scanning, and audit logs are foundational controls.

CI/CD credentials are especially sensitive because a compromised pipeline may deploy malicious code or access production data. Prefer workload identities or short-lived tokens over permanent keys. Separate development and production accounts or projects where practical, and require approval for high-risk production actions.

Governance includes data protection, retention, access logging, licensing, incident response, and regional requirements. Personal data should be collected and retained only for legitimate purposes, protected in transit and at rest, and removed according to policy. Production logs should be reviewed for accidental exposure of passwords, tokens, health information, or personal identifiers.

A secure deployment process also requires a rollback plan. Teams should know which version is safe, how database changes affect rollback, who can authorize the action, and how users will be informed during an incident.

11. Illustrative Case: Deploying a Student Marketplace

Background

A small team has developed a marketplace where students list used textbooks. The system contains a React frontend, a REST API, a relational database, image uploads, and an email notification worker.

Problem

The prototype runs on one developer laptop. It stores uploaded images locally, contains a database password in a configuration file, has no repeatable deployment method, and cannot safely handle two application instances. The team needs a public HTTPS address and a dependable recovery process.

Analysis

The system has both stateless and stateful components. The frontend and API can be packaged as immutable artifacts. Images and database records are persistent and must be externalized. Email delivery is asynchronous and should not delay a user’s listing request. The database is the most difficult component to replace and therefore deserves managed backups and migration discipline.

Approach

The team takes the following steps:

1. Places source code in a protected repository and adds automated tests.
2. Creates a CI pipeline that builds the frontend, tests the API, scans dependencies, and builds versioned container images.
3. Stores images in a private registry and deploys the API to a managed container service.
4. Stores uploaded images in object storage, using generated object identifiers rather than user-controlled file paths.
5. Uses a managed relational database with encrypted connections, automated backups, and restricted network access.
6. Places configuration in environment-specific settings and secrets in a secrets manager.
7. Creates DNS records for www and api, provisions TLS certificates, and redirects HTTP to HTTPS.
8. Adds a queue and worker for email notifications so the API can respond without waiting for the mail provider.
9. Runs migrations in staging before production and uses an expand-and-contract strategy for changes affecting active users.
10. Adds logs, request metrics, database monitoring, health checks, budget alerts, and a documented rollback procedure.

Outcome

The application can be reproduced from source, deployed consistently, and scaled horizontally. A failed API instance can be replaced without losing uploaded images. The team can restore the database from a tested backup and can identify unusual error rates through monitoring. Costs remain controlled by limiting non-production uptime, applying storage lifecycle rules, and reviewing resource utilization monthly.

Learning points

The case illustrates that deployment architecture is shaped by data ownership, failure behavior, security, and operational cost. Containers solve packaging and consistency problems, but they do not replace database backups, access control, or monitoring. A cloud service is valuable when its operational responsibilities are understood and managed deliberately.

12. Contemporary Developments and Practical Best Practices

Modern teams increasingly use infrastructure as code (IaC), in which networks, services, permissions, and deployment settings are represented in version-controlled definitions. IaC improves reviewability and repeatability, but it can also cause large-scale damage if applied without review or state protection.

Policy as code can automatically check whether infrastructure meets organizational requirements, such as encryption, approved regions, or mandatory tags. Software supply-chain security is also increasingly important. Teams should pin dependencies where appropriate, sign artifacts, generate software bills of materials, and restrict which images may run in production.

Platform engineering creates reusable internal deployment paths so application teams can deploy safely without mastering every infrastructure detail. Artificial intelligence may assist with log summarization, anomaly detection, or configuration suggestions, but generated changes require human review. AI tools can reproduce insecure code, expose confidential prompts, or produce false explanations; they should not receive production secrets or bypass approval controls.

A practical checklist is:

• Is the artifact versioned and reproducible?
• Are tests and security checks automated?
• Are secrets outside source control?
• Is the service reachable through a valid domain and TLS certificate?
• Are health checks, logs, metrics, and alerts available?
• Are database migrations backward-compatible where necessary?
• Are backups encrypted and restore-tested?
• Can the release be rolled back?
• Are permissions minimal and auditable?
• Are cost budgets and ownership tags configured?

Chapter Summary

Deployment is a controlled engineering process that transforms source code into a reliable production service. CI validates changes, while continuous delivery keeps validated artifacts ready for release and continuous deployment automates production promotion. Containers provide reproducible packaging, but persistent data belongs in appropriate storage and database services.

Cloud platforms offer IaaS, PaaS, serverless, and SaaS options with different responsibility boundaries. Configuration and secrets must be separated from code. DNS connects domain names to services, while TLS provides encrypted and authenticated communication. Database migrations require compatibility planning, and backups are meaningful only when restoration is tested.

Scaling may be vertical or horizontal, and observability depends on logs, metrics, traces, and actionable alerts. Little’s Law supports basic reasoning about concurrency, while availability and cost formulas provide useful estimates when their assumptions are understood. Security, governance, rollback planning, and cost control are integral parts of professional deployment rather than optional additions.

Key Terms

CI: Continuous integration; frequent integration of code with automated validation.

CD: Continuous delivery or continuous deployment, depending on context.

Artifact: A versioned output of a build, such as a package or container image.

Container: An isolated process environment created from an image.

Image: An immutable package used to create containers.

Registry: A service that stores and distributes container images.

Cloud computing: On-demand access to computing resources over a network.

IaaS: Infrastructure as a Service, providing virtualized infrastructure.

PaaS: Platform as a Service, providing a managed application platform.

Serverless: A model in which the provider manages server provisioning and scaling.

Configuration: Environment-specific settings controlling application behavior.

Secret: Confidential information such as a password, token, or private key.

DNS: Domain Name System, which maps names to network services.

TLS: Transport Layer Security, used to encrypt and authenticate network connections.

Migration: A controlled change to a database schema or data.

RPO: Recovery point objective, the maximum acceptable data-loss interval.

RTO: Recovery time objective, the maximum acceptable restoration time.

Observability: The ability to understand system behavior through logs, metrics, and traces.

Horizontal scaling: Increasing capacity by adding service instances.

Infrastructure as code: Managing infrastructure through version-controlled definitions.

Review Questions

Short Answer Questions

1. What is the difference between continuous delivery and continuous deployment?
2. Why should persistent application data normally not be stored inside a container’s writable layer?
3. What is the purpose of a TLS certificate?
4. Define RPO and RTO.
5. Name the three principal forms of observability data.

Long Answer Questions

1. Explain the stages of a CI/CD pipeline and discuss why the same artifact should be promoted from staging to production.
2. Compare virtual machines, containers, managed platforms, and serverless services for a small full-stack application.
3. Describe a safe database migration strategy for an application that must remain available during deployment.
4. Explain how DNS, domain names, HTTPS, and TLS work together in a public web deployment.
5. Discuss the shared-responsibility model in cloud computing and its implications for application security.

Analytical / Application Questions

1. An API receives 30 requests per second and has an average response time of 0.2 seconds. Use Little’s Law to estimate the average number of in-flight requests, and state the assumption behind the calculation.
2. Design a deployment plan for a web application that has a frontend, API, relational database, image uploads, and background email jobs. Identify which components should be stateless and which require persistent storage.
3. A team wants to reduce cloud cost by disabling backups, monitoring, and TLS on its development and production systems. Evaluate this proposal and recommend safer cost-control alternatives.

Multiple Choice Questions with Answers

Question 1

Which activity is most directly associated with continuous integration?

A. Manually copying files to a production server

B. Automatically building and testing code after changes are integrated

C. Buying a domain name

D. Increasing database storage without testing

Correct Answer: B. Automatically building and testing code after changes are integrated

Question 2

What is the main advantage of building one artifact and promoting it through environments?

A. It guarantees zero defects

B. It ensures staging and production use exactly the same built output

C. It removes the need for configuration

D. It eliminates the need for monitoring

Correct Answer: B. It ensures staging and production use exactly the same built output

Question 3

Where should a production database password normally be stored?

A. In a public source-code repository

B. Inside a frontend JavaScript file

C. In a controlled secrets-management system

D. In the container image description

Correct Answer: C. In a controlled secrets-management system

Question 4

Which DNS record maps a hostname to an IPv4 address?

A. MX

B. TXT

C. A

D. NS

Correct Answer: C. A

Question 5

What does a readiness check determine?

A. Whether a process can safely receive traffic

B. Whether the source code has been formatted

C. Whether a domain has expired

D. Whether a backup is encrypted

Correct Answer: A. Whether a process can safely receive traffic

Question 6

An API receives 20 requests per second and has an average response time of 0.5 seconds. Using Little’s Law, what is the average number of in-flight requests?

A. 4

B. 10

C. 20

D. 40

Correct Answer: B. 10

Question 7

Which deployment strategy sends a small percentage of traffic to a new version before wider release?

A. Canary deployment

B. Cold backup

C. Vertical partitioning

D. Full replacement without monitoring

Correct Answer: A. Canary deployment

Question 8

What does RPO describe?

A. The maximum acceptable time to restore service

B. The maximum acceptable amount of data loss measured in time

C. The number of production instances required

D. The cost of a database transaction

Correct Answer: B. The maximum acceptable amount of data loss measured in time

Question 9

Which is an example of horizontal scaling?

A. Adding memory to one server

B. Changing a processor to a faster model

C. Adding more application instances behind a load balancer

D. Compressing a log file

Correct Answer: C. Adding more application instances behind a load balancer

Question 10

Which practice most directly supports cloud cost control?

A. Leaving unused development resources running indefinitely

B. Disabling all security controls

C. Applying budgets, rightsizing resources, and removing unused assets

D. Storing every backup forever

Correct Answer: C. Applying budgets, rightsizing resources, and removing unused assets