MODULE-IV

Deployment: Twelve Factor Apps, Developer Machines, Production Environments,

Movingcode into Production, Infrastructure, Immutable infrastructure, Continuous
Delivery andContinuous Deployment

Deployment: "Deployment isn’t an afterthought—it influences how you build your

application."

You should not wait until the end of your project to think about how your application will be
deployed or run in a live environment. Instead, you need to consider the deployment
environment right from the beginning, because it can affect the way you design and build
your application.

🔍 Example Breakdown:

 If your app will run on multiple servers (horizontal scaling),you can’t store user
sessions in memory, because each server won’t know what the other is storing.
You’ll need to store session data in a shared database or cache, like Redis.
 If your users upload large files, and the deployment server has limited disk space,
you might need to use cloud storage (e.g., AWS S3) instead of saving files locally.

Dev + Ops = DevOps

 The DevOps movement seeks to eliminate silos between development and

operations.
 Instead of developers “throwing code over the wall”:
o Developers understand the production environment constraints.
o Ops help create better environments for the app to thrive.
 Collaboration is the central theme.

Continuous Delivery (CD)

 Encourages frequent and early releases to reduce waste and avoid unused builds.
 Builds on Continuous Integration (CI):
o CI = Regularly integrating code.
o CD = Regularly delivering that code to production.
 Mature teams:
o Push even the earliest "Hello World" versions to production.
o Automate the entire deployment pipeline.
o Can spin up new environments quickly and reliably.

Twelve-Factor App methodology

it's like a set of best practices for building modern, cloud-friendly, and easy-to-maintain
apps. Originally created by Heroku, these principles help developers avoid common
deployment problems and ensure the app is ready for scale and flexibility.

1. One Codebase Tracked in Version Control, Many Deploys

 One source of truth (like a Git repo) for your code.
 Same codebase used in different environments (dev, test, production).
 No separate code for production/testing – just different versions of the same code.
2. Explicitly Declare and Isolate Dependencies

 Always list what your app needs to run (like libraries, packages).
 Don't assume the system has what you need.
 Keep dependencies bundled with the app, so setup is easy and repeatable.

3. Store Configuration in the Environment

 Don't hardcode things like passwords or URLs.

 Use environment variables (like .env files or config managers) for app-specific
settings.
 Makes it easy to change things like database credentials without touching code.

4. Treat Backing Services as Attached Resources

 Databases, caches, and other services are “add-ons” that can be plugged in/out.
 Your app shouldn’t care where the service runs — just that it’s available.
 Makes switching services (like moving from local DB to cloud DB) simple.

5. Build, Release, Run

 Keep these stages separate:

o Build – Turn code into a deployable format.
o Release – Combine build with config to make a version.
o Run – Actually run the app.
 Makes rollbacks and tracking easier.

6. Execute the App as One or More Stateless Processes

 Don’t store things (like session info or files) in app memory or local disk.
 Use shared services (like Redis or cloud storage) to save data.
 Stateless apps are easier to scale and move.

7. Export Services via Port Binding

 Your app should be accessible through a network port (like localhost:3000).

 Makes it easier to deploy and scale across different machines or containers.

8. Scale Out via the Process Model

 Your app should be easy to scale by running more processes.

 Can split responsibilities (web server, background jobs) into separate processes.
 This makes handling heavy loads more flexible.

9. Maximize Robustness with Fast Startup and Graceful Shutdown

 Start quickly and clean up properly when shutting down.

 If something goes wrong, restart without hassle.
 Helps with zero-downtime deployments and scaling.

10. Keep Development, Staging, and Production as Similar as Possible

 Environments (like dev and prod) should behave similarly.

  Reduces "works on my machine" problems.
 Makes transitions smoother and bugs easier to catch early.

11. Treat Logs as Event Streams

 Don’t manage log files.

 Write logs to stdout/stderr (console), and let a logging service handle them.
 Makes logs easier to view, search, and manage centrally.

12. Run Admin/Management Tasks as One-off Processes

 Database migrations, cleanup scripts, etc., should be separate commands.

 Run them as needed without interfering with your main app.
 Helps keep your app’s core simple and clean.

Developer Machines
The way developers set up their local development environments matters a lot for efficiency,
consistency, and smooth deployment.

What’s the problem?

 Old way: Developers used to install everything directly on their personal computers
(e.g., using tools like MAMP on Windows or macOS).
o ❌ This leads to inconsistencies—code might run differently on one machine
vs another.
o ❌ Hidden problems appear when moving code to production (like missing
software or different paths).

What’s the modern solution?

1. Virtual Machines (VMs):
o Use tools like Vagrant to create a clean, repeatable setup.
o Every developer gets the exact same environment using a Vagrantfile.
o They just run vagrant up to spin up the whole environment.
2. Containers (e.g., Docker):
o Like VMs, but lighter and faster.
o Each component (e.g., app, database) runs in its own separate container.
o Useful for both development and production.
o Requires orchestration (like Docker Compose or Kubernetes) to manage
complex apps with multiple services.

Developers should not have to struggle for hours just to run the code on their machine.
Tools like Vagrant and Docker allow for fast, automated, and identical setups for everyone
on the team.

Production Environments :
You can't use development tools like Vagrant directly in production. But the
deployment process should still be automated, consistent, and repeatable, using code-
based configuration.

Why not use Vagrant for production?

 Vagrant is great for local development only.

  It lacks:
o Fine control over production settings (e.g., firewalls, scaling, backups).
o Stability for real-world deployments.
 Local setups often use:
o Shared folders
o Hot reloading
o Debug mode
...all of which are not suitable for production.

What should you do?

 Reuse what you can from local environments in production (e.g., build scripts,
container images).
 Use tools like:
o Docker (to package your app the same way for local & prod)
o Infrastructure-as-Code tools (e.g., Terraform, AWS CloudFormation) to
automate environment setup.

Best Practices:
1. Multiple Environments:
o Local → QA → UAT → Staging → Production
o All treated like “mini-productions”—no special cases.
2. Use Configuration Files:
o Different instance sizes or URLs? No problem.
o Use parameterized templates to express differences.
o Example: use the same code, just swap the config.
3. Version Everything:
o Infrastructure code (like your app code) should be:
 Stored in Git
 Versioned
 Deployed together with app changes

Moving Code into Production:

In a DevOps culture, the development team owns the responsibility for everything,
including how the app runs in production—not just writing the code.

� 1. Traditional vs. DevOps Deployment

Traditional Way:
 Ops team gives you a server.
 You SSH into it, clone the code from Git, run npm install, etc.
 This approach is error-prone:
o Dependency mismatches (e.g., different Node.js versions)
o Outages from external services (e.g., NPM down)
o Manual steps = more mistakes

DevOps Way:
 Build, deploy, and run are separated (a 12-factor app principle).
 You should build your app once, then deploy the same ready-to-run package
everywhere (like QA, staging, production).

2. Package Your Application

Instead of copying raw source code to servers, create deployable packages:
  � Java: Use a .jar
 🐧 Linux:
o Use .deb (Debian/Ubuntu) or .rpm (RedHat/CentOS)
o These can specify dependencies and run post-install scripts
o Example: start your app using systemd with systemctl enable my-app

This makes your app behave like any other system-installed software.

� 3. Why is Packaging Powerful?

 You control what gets installed
 You bundle everything needed to run, not to build
 It’s easier to:
o Automate installs
o Ensure consistency across environments
o Handle start/stop behavior with native OS tools

� 4. App Dependencies vs OS Dependencies

Keep them separate:

App-Level Dependencies OS-Level Dependencies

Libraries like node_modules, vendor Language runtime (Node, PHP, etc.)

Bundled inside your package Managed via package manager (apt, yum)

Installed using npm, composer, etc. Examples: NodeJS, ImageMagick, libxml

🐳 5. Containers = Next-Level Packaging

If you’re using Docker or containers:

 Your container image is the deployable unit

 Think of it as a pre-built package
 Still follow the same principle: build once, deploy anywhere

Deploying should be as easy as:

🔹 apt install your-app
🔹 or docker run your-image

The build process happens before deployment, often in CI/CD pipelines (e.g., Jenkins,
GitHub Actions). The final package or container is pushed to a repository, ready to be
deployed anywhere.

Configuring Your Box :

Installing your app’s package is only part of the job—you still need to configure the box
(server/VM/container) it runs on. That includes setting up:

 Your app's environment

 Supporting services (like databases)
 OS-level settings
 Security rules
  Monitoring and logging tools

1. Standardize Environments
Differences between prod, QA, and test environments should be:

 🔽 Minimized
 ✅ Managed consistently

Examples:

 ✅ Okay: Higher logging level in test

 ❌ Not Okay: Different versions of a database across environments

2. Tools to Automate Configuration

You can start with basic shell scripts, but there are more powerful configuration
management tools, like:

Tool Description

Ansible Agentless, YAML-based configuration management

Puppet Declarative language to define system state

Chef Ruby-based, flexible automation tool

These tools focus on desired state configuration:

You describe what the system should look like, and the tool ensures it matches that state.

3. Configure Your Application (The 12-Factor Way)

 Don’t hard-code configs
 Prefer environment variables for configuration
 Optionally use config.json or .ini files
 Use automation tools to inject the right config at deployment time

🛑 Avoid bundling environment-specific config into your codebase.

4. Infrastructure Configuration

Beyond your app, configure system-level components:

 🔥 Firewall rules
 👤 SSH users and permissions
 📊 Monitoring tools (like Prometheus or Datadog agents)
 � Log forwarding agents (e.g., sending logs to a centralized system)

Automate these with Ansible/Chef/Puppet.

5. Benefits of Automation

Once all configurations are scripted:

 🚀 Easy to deploy in any environment

  � Spin up new test environments quickly
 🔄 Re-run scripts to reconfigure or redeploy confidently

SSH Bastions (Jump Hosts)

You shouldn’t expose your production machines directly to the internet.

✅ Best Practice:

 Put all production servers behind a firewall

 Use an SSH bastion (also called jump host) to:
o Accept SSH connections from developers
o SSH into individual internal servers from there

🛡️ This adds a security layer while still giving access for troubleshooting.

What You Need to Do

1. 📦 Package your app

2. ⚙️ Use config management tools for:
o App config
o Infra config
o OS-level config
3. 🛡️ Secure access via SSH bastions
4. 🔄 Automate everything to simplify deployment

Infrastructure and Deployment:

1. Beyond Code Installation:

 Deployment isn’t just about copying code—configuration matters.

 Different environments (dev, test, prod) should have minimal differences to avoid
bugs and deployment failures.

2. Configuration Management Tools:

 Tools like Ansible, Puppet, and Chef help define and maintain the desired state of
your systems.
 Environment variables, .ini, or JSON files are common ways to inject configuration
without hardcoding values.

3. Infrastructure as Code (IaC):

 Infrastructure should be scripted, repeatable, and version-controlled.

 Terraform and AWS CloudFormation are popular IaC tools for provisioning
infrastructure using code templates.

4. Automation is Critical:

 Automation builds confidence and reproducibility in deployments.

 Even firewall rules, user SSH access, and log configurations should be
automated.
5. SSH Bastions:

 Secure your environment with SSH bastions (jump boxes) instead of exposing
every server to the internet.
 Developers SSH into the bastion and then access internal servers securely.

6. Types of Infrastructure:

 Compute: Virtual Machines (VMs), containers, or serverless functions.

 Network: Load balancers, DNS nameservers, firewalls.
 Storage: Databases, object stores, file systems.
 Utilities: Message queues, caches, CDNs, logging, monitoring.

7. PaaS vs IaaS:
Feature PaaS (Platform-as-a-Service) IaaS (Infrastructure-as-a-Service)

Control Limited Full

Complexity Simpler Higher

Flexibility Constrained Customizable

Examples Heroku, App Engine AWS EC2, GCP Compute Engine

 PaaS is easier to start with but has limitations (OS, storage, runtime).
 IaaS gives more control but requires managing complexity.

8. Private Cloud:

 "Private cloud" replicates cloud services in your own data center.

 Often less flexible and less mature than public cloud offerings.

9. Parameterization:

 Use templates with dynamic values (e.g., instance size, AMI ID).
 Helps reuse definitions across environments with minor tweaks.

10. Local Development:

 Local setup can be lightweight and fast but might not mimic production exactly
(e.g., no CDN or LB).
 Tools like Docker help simulate infrastructure to reduce surprises at deployment.

11. Vendor Lock-In vs Flexibility:

 Relying on cloud-native tools boosts productivity but can lead to vendor lock-in.
 Aim for portability and standardized interfaces to stay flexible.

Immutable Infrastructure
Definition:
Immutable infrastructure means once your app is deployed, the infrastructure and code
do not change. If updates are needed, you replace the old components with new versions
instead of modifying them in place.
Why Use Immutable Infrastructure?
 Prevents “fragile” setups caused by undocumented or incremental changes.
 Ensures all changes are intentional and reproducible.
 Supports consistent environments across dev, test, and prod using the same
code/configuration.

Phoenix Deployment Pattern

“Burn it down and build it again”

 Regularly destroy and rebuild environments from scratch.

 Ensures your app can be deployed cleanly at any time.
 Avoids relying on leftover artifacts like log directories or hidden configs.

Blue-Green Deployment Strategy

 Two identical production environments:

o One is live (e.g., Blue).
o The other is idle (e.g., Green).
 New version is deployed to the idle one.
 You can test and gradually shift traffic ("canary deployment").
 If something goes wrong, roll back by switching back to the previous environment.

How Statelessness Helps

 Works best with 12-factor apps, especially those that are stateless.
 Application state (like user sessions, files, etc.) is stored in external services (e.g.,
databases, object storage).
 Even for stateful services like databases, you can treat the data disk as external,
while the app and infra around it remain immutable.

Continuous Delivery and Continuous Deployment

1. Continuous Delivery:
o A set of engineering principles to reduce the time needed to make changes
to software.
o Focuses on automating the pipeline—the stages a feature or change goes
through before delivery.
o You might still have a manual gate at the end for checks (e.g., human sanity
checks).
o Ensures features are always ready for deployment but does not require
immediate deployment.
2. Continuous Deployment:
o Every change is automatically deployed to the live environment from
development.
o Fully automated and requires discipline.
o Often triggered by a CI/CD server like Jenkins or GoCD.
o The idea is to have a single command that deploys the latest version to the
environment.

Challenges with Continuous Delivery

  Merging Risks: In Continuous Integration (CI), multiple commits are merged
continuously, but with continuous delivery, you want to avoid premature releases
while ensuring that code is always ready to go.
 For teams not practicing pure CI, feature work is often kept in a feature branch until
completed, but this can make releasing quick fixes more difficult.

Feature Flags (Toggles)

 A code mechanism to help manage the release of features without affecting
production.
 Can enable/disable a feature based on an external configuration (e.g., a config file
or environment variable).
 Core idea: An if statement around the code disables a feature if the flag is off,
keeping the app stable.

Benefits of Feature Flags

 Smooth rollouts: You can gradually release a new feature to specific users or
environments.
 Rolling back features: If there’s an issue, you can disable the feature by changing
a config, instead of rolling back code or a full deployment.
 A/B Testing: Feature flags can serve different variants to users, allowing you to run
usability tests on a large scale.