DEV Community: lotanna obianefo

Inside .git, Objects & Hashing

lotanna obianefo — Mon, 22 Jun 2026 15:02:37 +0000

Understanding what happens inside the hidden .git directory is one of the most important steps toward mastering Git. It helps explain why Git is fast, reliable, and capable of tracking millions of changes across large software projects.

When you initialize a repository with git init Git creates a hidden directory called .git/. It contains everything Git needs to track changes, manage versions, store commit history, and maintain the overall state of your project.

Git Objects is the building blocks that make up your repository. Together, they allow Git to efficiently store and track project history. Object is the basic unit of storage used internally by Git. Every piece of information in a repository is stored as one of these four object types;

Blob for Storing file contents
Tree for Storing directory and file structure
Commit for Storing a snapshot of the repository and metadata
Tag for Storing references to specific releases or versions

Hashing is the process of converting data into a unique, fixed-length identifier called a hash. Git uses the SHA-1 hashing algorithm to generate these identifiers.
This hash acts like a unique fingerprint for the content. If the content changes, even by a single character, Git generates a completely different hash.

Now let's perform a mini project to help understand these...

Initialise & Explore the .git Directory

Initialize a new Git repository and examine the hidden .git directory to understand how Git stores and manages commits, branches, configuration files, and other version control data behind the scenes.

1. Initialise a New Repository

This step creates a new working directory, initializes a Git repository using git init, and verifies the repository's state with git status. During initialization, Git generates a hidden .git directory that contains the internal database and configuration files required for version control.

The git init command is the starting point of every Git workflow. It creates the foundational repository structure that Git uses to store objects, track changes, manage branches, and maintain commit history. Without a .git directory, Git cannot record versions, store metadata, or perform any version control operations.

Understanding what git init does behind the scenes helps build a solid foundation for learning Git, as every commit, branch, tag, and repository operation depends on the database structure it creates.

Every software project should begin with a properly initialized repository. Establishing version control from the start promotes consistency, traceability, and effective collaboration throughout the software development lifecycle.

      # Creates a new directory (folder).
       mkdir git-internals-lab

      # Changes the current directory.
       cd git-internals-lab

      # Initializes a new Git repository in the current directory.
       git init

      # Shows which files are staged, modified, or untracked your current working state.
       git status

2. Tour the .git Directory

This step examines the contents of the hidden .git directory, including key components such as HEAD, config, objects, refs, hooks, and info. It also inspects files like HEAD, which identifies the currently checked-out branch, and config, which stores repository-specific settings.

The .git directory is the core of every Git repository. It contains all the information Git uses to manage version control, including commit history, branches, tags, configuration settings, and object storage. Files such as HEAD act as pointers to the current branch, while the objects directory stores Git's internal database and refs maintains references to branches and tags.

Understanding the structure of the .git directory provides valuable insight into how Git operates behind the scenes. This knowledge helps demystify advanced concepts such as branching, rebasing, reflog inspection, repository recovery, and troubleshooting version control issues.

      # Lists files and directories. -l shows details (permissions, size, date).
       ls .git

      # Displays the contents of Git's HEAD file
       cat .git/HEAD

      # Displays the repository's local configuration file
       cat .git/config

      # lists the contents of the Git refs directory
       ls .git/refs

Hashing & Blob Objects

Generate your first SHA hash and observe how Git converts a file into a content-addressed blob object stored in the object database. The SHA hash acts as a unique identifier based on the file's contents, allowing Git to track and retrieve the file efficiently without relying on its filename or location.

1. Create a File and Hash It

Writes "Hello Git" to hello.txt and instructs Git to calculate the file's SHA-1 hash without storing the file as an object. The resulting hash (for example, 9f4d96d5b00d98959ea9960f069585ce42b1349a) serves as a unique content fingerprint that identifies the file based solely on its contents.

Git tracks data by its hash rather than its filename. Identical content always produces the same hash, while even a one-character modification generates an entirely different hash. This content-addressable design makes Git history tamper-evident, as altering a file changes its hash and invalidates every reference that depends on it.

Cryptographic hashing helps ensure the integrity and authenticity of repository data.

       # Prints text to the terminal — also used to write to files with > or >>.
        echo 'Hello Git' > hello.txt

       # Runs a Git version control command.
        git hash-object hello.txt

2. Write the Blob to the Object Store

The -w flag tells Git to store the file as a blob object in the .git/objects directory. Using find reveals that Git stores the object at .git/objects/first-2-chars/remaining-38-chars, splitting the hash into a directory and filename to prevent a single directory from containing too many files.

An object's hash determines its storage location. Identical files produce the same hash and are stored only once, reducing duplication while allowing Git to efficiently manage millions of objects.

Hash-based directory sharding enables fast object lookups and maintains filesystem performance as repositories grow.

        # Runs a Git version control command.
        git hash-object -w hello.txt

        # Searches for files and directories matching criteria (name, type, size, date, etc.).
        find .git/objects -type f

        # Lists files and directories. -l shows details (permissions, size, date).
         ls .git/objects

3. Inspect the Blob with cat-file

git cat-file -t displays the object's type (such as blob), while git cat-file -p prints the object's contents in a human-readable format. Replace the example hash with the hash generated in your environment, the output will be identical if the file contents are the same.

A blob object stores only the file's contents. it does not contain the filename, directory path, or commit history. This is why multiple files with identical content can reference the same blob object. File names and directory structures are stored separately in tree objects.

Low-level Git commands such as cat-file provide valuable insight into Git's internal data model and can assist with troubleshooting, data recovery, and advanced repository management.

             # Runs a Git version control command.
              git cat-file -t 9f4d96d5b00d98959ea9960f069585ce42b1349a

             # Runs a Git version control command.
              git cat-file -p 9f4d96d5b00d98959ea9960f069585ce42b1349a

Commits, Trees & Snapshots

Stage and commit your file, then observe how Git represents a project snapshot using three core object types: blob, tree, and commit.

In this structure, a blob stores the file contents, a tree represents the directory hierarchy, and a commit ties everything together with metadata such as the author, timestamp, and a reference to the root tree object. This object model is what enables Git’s efficient version tracking and history reconstruction.

1. Stage and Create the First Commit

Configures your Git identity for commit attribution, stages hello.txt, creates the initial commit, and displays the commit history using the log.

During this process, Git builds its internal object graph. A blob stores the file content, a tree represents the directory structure, and a commit object references the tree while also capturing metadata such as author, timestamp, and message.

Specifically, git add writes the file content as a blob and records it in the staging index, while git commit converts the staged index into a tree snapshot and then creates a commit object pointing to that tree. Together, these three objects form a single atomic snapshot of the repository state, which becomes the fundamental unit of Git history.

This supports Operational Excellence by enabling atomic, immutable snapshots that allow safe rollbacks, efficient debugging, and reliable history traversal like bisecting changes.

      # Sets Git configuration email.
      git config --global user.email 'you@example.com'

      # Sets Git configuration name.
      git config --global user.name 'Your Name'

      # Stages the specified file(s) for the next commit.
      git add hello.txt

      # Creates a new commit with all staged changes and the message after -m.
      git commit -m 'Initial commit'

      # Shows the commit history. --oneline condenses each commit to one line, --graph shows branches visually.
      git log --oneline

2. Inspect the Commit Object

git rev-parse outputs the SHA-1 (or SHA-256) identifier of the current commit. git cat-file -t verifies the object type as a commit, while git cat-file -p displays its full internal structure, including the referenced tree SHA, author and committer metadata, timestamp, parent commit reference(s), and commit message.

A commit object itself does not store file contents. Instead, it contains metadata (author, committer, timestamps, parent commit SHA, and message) and a single reference to a tree object, which represents the project’s directory snapshot. That tree, in turn, references blob objects that store the actual file contents.

This supports Security by providing cryptographic identifiers and immutable history, enabling accurate traceability, forensic auditing, and verification of who made each change and when.

      # Runs a Git version control command.
      git rev-parse HEAD

      # Runs a Git version control command.
      git cat-file -t HEAD

      # Runs a Git version control command.
      git cat-file -p HEAD

3. Inspect the Tree Object

git ls-tree displays the contents of a tree object, which represents a snapshot of a directory in Git. The TREE variable typically resolves to the tree SHA referenced by HEAD, and git cat-file -p reveals its entries in the format. File mode (e.g., 100644), object type (blob or tree), object SHA, and filename (e.g., hello.txt).

A tree object functions as a mapping between filenames and their corresponding object hashes. It can point either to blob objects (files) or to other tree objects (subdirectories), thereby reconstructing the project’s directory hierarchy. This is the mechanism through which Git restores filenames and directory structure on top of its content-addressable storage. The file mode (such as 100644) represents Unix-style permission metadata.

This supports Operation by enabling deep inspection of repository structure, which is critical for debugging diffs, analyzing history, and performing precise, targeted history modifications.

      # Runs a Git version control command.
      git ls-tree HEAD

      # Sets the shell variable TREE so later commands can reference it with $TREE.
      TREE=$(git rev-parse HEAD^{tree})

      # Runs a Git version control command.
      git cat-file -p $TREE

4. Observe Snapshots, Not Deltas

Compares the number of Git objects before and after making a small change to a file. After the second commit, Git typically creates three new objects: a blob containing the updated file content, a tree representing the updated directory structure, and a commit object representing the new repository snapshot. As a result, the total object count increases by three.

Git's architecture is based on immutable snapshots rather than modifying existing objects. Each commit references a complete tree that represents the state of the repository at a specific point in time. When changes are made, Git creates new objects while preserving all previous ones unchanged. This design allows you to instantly check out historical commits, reliably reconstruct repository states, and maintain a highly resilient version history.

This supports Reliability by ensuring that every commit is an immutable, independently recoverable snapshot, providing robust protection against data loss and enabling safe rollback to any previous state.

      # Searches for files and directories matching criteria (name, type, size, date, etc.).
       find .git/objects -type f | wc -l

      # Prints text to the terminal & also used to write to files with > or >>.
       echo 'Another line' >> hello.txt

      # Stages the specified file(s) for the next commit.
       git add hello.txt

      # Creates a new commit with all staged changes and the message after -m.
       git commit -m 'Updated file'

      # Searches for files and directories matching criteria (name, type, size, date, etc.).
       find .git/objects -type f | wc -l

Refs, HEAD & Publishing to GitHub

Trace the HEAD → Branch → Commit → Tree → Blob reference chain to understand how Git locates and reconstructs a project snapshot. Then push the repository to GitHub and observe how Git transfers all required objects commits, trees, and blobs to the remote repository, preserving the complete history and structure of your project.

1. Trace HEAD and Branch Refs

Reads the HEAD file, which typically contains a reference such as ref. refs/heads/main, and then reads the corresponding branch reference file, which stores the SHA of the latest commit. Running git rev-parse HEAD and git rev-parse main returns the same commit SHA, demonstrating how Git resolves references through a chain of indirection.

HEAD is a symbolic reference that points to a branch rather than directly to a commit. The branch itself is a lightweight reference that stores the SHA of the latest commit. When a new commit is created, Git generates a new commit object and updates the branch reference to point to it, while HEAD continues to reference the branch. This design makes branches inexpensive to create and update, and also explains detached HEAD state, where HEAD points directly to a commit instead of a branch.

Understanding how HEAD and branch references work helps prevent common Git issues such as detached HEAD states, lost commits, and accidental branch overwrites.

      # Runs a Git version control command.
       cat .git/HEAD

       cat .git/refs/heads/main

       git rev-parse HEAD


      # Runs a Git version control command.
       git rev-parse main

2. Set Up SSH Auth and Add a Remote

Generates an Ed25519 SSH key pair and adds the public key to GitHub (Settings → SSH and GPG keys) to enable secure authentication.
Next, registers a GitHub repository as the origin remote. Before doing so, create an empty repository on GitHub and avoid initializing it with a README, .gitignore, or license file to prevent conflicts with your local repository.

A remote is a named reference to another Git repository, allowing Git to exchange commits and objects between locations. Ed25519 SSH keys are the modern standard for Git authentication, providing strong cryptographic security, faster key operations, and passwordless access. Once the origin remote is configured, Git knows where to send (push) and retrieve (pull) repository data.

SSH key-based authentication replaces password-based workflows with cryptographic identity verification, improving both security and automation compatibility.

      # Stages the specified file(s) for the next commit.
       ssh-keygen -t ed25519 -C 'you@example.com'

       cat ~/.ssh/id_ed25519.pub

       git remote add origin git@github.com:<YOUR_USERNAME>/git-internals-lab.git

      # Manages remote repository connections (origin, upstream, etc.).
      git remote -v

3. Push Every Object to GitHub

Uploads all reachable Git objects blobs, trees, and commits to the remote repository and updates the remote branch reference (e.g., main) to point to your latest commit. The -u flag sets origin/main as the upstream tracking branch, enabling simplified future push and pull operations. git ls-remote can be used to inspect and verify the current references stored on the remote.

A git push operation is fundamentally object replication combined with a reference update. Git ensures that the remote repository stores the exact same objects as your local repository, identified by identical SHA-1 (or SHA-256) hashes. As a result, the commit history, file contents, and directory structure remain fully consistent across environments, meaning GitHub reconstructs the same tree and blob relationships you have locally.

This supports Reliability by leveraging Git’s distributed architecture, where every clone contains a complete, self-contained history, enabling redundancy, integrity, and full recoverability of the repository state.

      # Uploads your local commits to the remote repository.
      git push -u origin main

      # Manages remote repository connections (origin, upstream, etc.).
      git ls-remote origin

Although Git appears simple on the surface, it is powered by a sophisticated object database and hashing system. Every file, directory, and commit is stored as an object identified by a unique hash, allowing Git to efficiently track changes and maintain repository integrity.

Local Machine to GitHub Repo

lotanna obianefo — Tue, 16 Jun 2026 22:22:45 +0000

Version control is a fundamental practice in modern software development and DevOps. It enables developers to track changes, collaborate efficiently, and maintain a complete history of their codebase. One of the most widely used version control systems is Git, while GitHub provides a cloud based platform for storing and managing Git repositories.

In this project, we will explore the complete process of moving code from a local machine to a GitHub repository. By the end, you will understand how to initialize a Git repository, track changes, create commits, connect to GitHub, and push your code to a remote repository.

Workspace Preparation:

Install the terminal environment and tools required to perform Git operations on Windows or macOS. This environment allows you to execute Git commands for version control, repository management, and collaboration.

1. GitBash

Download and install the official Git package for your operating system (Windows, macOS, or Linux). The installer includes Git and the tools required to perform version control operations from the command line.

Git Bash provides a Unix-like command-line environment on Windows, allowing users to execute Git commands and work with shell utilities commonly used in software development, cloud computing, and DevOps workflows. It offers a consistent experience similar to Linux and macOS terminals, making it an industry standard tool for developers and DevOps engineers.

Using standardized tools and environments across the software development lifecycle promotes operational excellence by improving consistency, collaboration, and automation. A common command-line interface helps teams reduce environment specific issues, streamline workflows, and maintain reliable development and deployment processes.

       # Visit: https://git-scm.com/downloads

Global Identity Configuration

Before creating commits, configure your global Git profile by setting your username and email address. Git uses this information to identify the author of each commit, ensuring that all changes are correctly attributed to you across your repositories.

Properly configuring your Git identity improves traceability and accountability, making it easier to track contributions, collaborate with other developers, and maintain an accurate project history.

1. Set Global Username

Configures your identity in the global .gitconfig file on your local machine, ensuring that all commits are consistently attributed to you.

Git is a distributed version control system, and every change must be associated with an author identity to support traceability, collaboration, and accountability across teams.

This follows the principle of operational excellence by maintaining clear ownership, auditability, and a reliable history of changes within the codebase.

      git config --global user.name "Your Name"

2. Set Global Email

Associates your email address with all commits made from your local Git environment.

This email is used by platforms such as GitHub to map your local Git activity to your remote user profile, including your avatar, contribution history, and activity graph.

From a security and governance perspective, this ensures that every commit is tied to a verifiable identity, supporting authentication, traceability, and accountability within collaborative development workflows.

      git config --global user.email "your-email@example.com"

Local Repository Initialization

Create a dedicated project directory and initialize a Git repository within it.

This sets up Git's version control framework by creating a hidden .git directory, enabling the project to track file changes, manage revisions, and support collaborative development workflows from the start.

1. Create Project Directory

Creates a new directory named website and changes the terminal's current working directory to that location.

Organizing each project in its own dedicated directory helps prevent accidental file modifications, simplifies project management, and maintains a clean and structured development environment.

This aligns with the principle of Operational Excellence by promoting effective workspace organization, consistency, and maintainability across projects.

      # Creates a new directory (folder).
      mkdir website

      # Changes the current directory.
      cd website

2. Initialize Git Engine

Initializes a Git repository by creating a hidden .git directory, which acts as the local database for storing version history, configuration settings, and metadata related to your project.

Without this initialization step, Git cannot monitor file changes, record commit history, or provide version control capabilities.

This supports the principle of Reliability by establishing a solid foundation for change tracking, version management, and recovery from unintended modifications.

      # Initializes a new Git repository in the current directory.
       git init

Artifact Creation

Create your first web asset within the project directory.

This file serves as the foundation of your web application and becomes part of the source code that Git can track, version, and manage throughout the development lifecycle. Starting with a structured project asset helps establish good development and version control practices from the outset.

1. Generate index.html

Creates an empty file named index.html in the current working directory.

The index.html file serves as the default entry point for most web servers and static hosting platforms such as GitHub Pages, allowing it to be automatically loaded when a user accesses a website root.

This follows the principle of Reliability by adhering to standard web conventions, ensuring predictable behavior and consistent application structure across hosting environments.

      # Creates an empty file or updates the timestamp of an existing one.
       touch index.html

Content Authoring (Vi/Vim)

Learn how to use an industry-standard command-line text editor to create and manage your website content.

This skill enables you to efficiently edit files directly from the terminal, which is essential for remote development environments, server management, and professional software engineering workflows where graphical editors may not be available.

1. Open File in Vim

Opens the index.html file in the Vim text editor for direct modification within the terminal.

Editing files via the command line is a fundamental skill in DevOps and system administration, particularly in environments where GUI-based editors are unavailable, such as remote servers and containers.

This aligns with Operational Excellence by promoting proficiency in terminal-based tooling, improving efficiency, and enabling consistent development across diverse environments.

      vi index.html

2. Enter Insert Mode

Switches Vim from Normal Mode to Insert Mode, enabling direct text input and file editing.

Vim is a modal text editor, meaning different modes are used for navigation and editing. Insert Mode must be explicitly activated before content can be added or modified.

This supports Operational Excellence by enabling efficient, precise text manipulation through a structured, mode-based editing workflow.

      # Press 'i' on your keyboard

3. Add Website Content

Adds the website’s HTML structure and content to the file.

This markup defines what is rendered in the browser and determines how users will view and interact with the webpage when it is deployed.

This aligns with Reliability by ensuring the application has a valid, well-defined entry point that can be correctly interpreted and displayed by web browsers.

      # Paste your HTML content (Resume, Website, etc.)
      # TIP: You can generate a sample resume template!

4. Save and Exit

The command :wq in Vim means write and quit, where w saves the current changes to disk and q exits the editor.

Writing ensures that all modifications are persisted to the file system, while quitting returns you to the terminal environment (e.g., Git Bash) to continue executing commands.

This supports Operational Excellence by promoting safe, intentional file handling and ensuring changes are explicitly saved before exiting the editing session.

      # 1. Press 'ESC' to return to Normal Mode
      # 2. Type ':wq' and press Enter

Staging Changes

Prepare your authored content for inclusion in a repository snapshot.

This means organizing and staging your modified files so they are ready to be recorded as part of a Git commit, creating a consistent and trackable version of your project’s current state.

1. Stage the File

Adds the file from the Working Directory to Git's Staging Area, marking it for inclusion in the next commit.

The staging area acts as an intermediate layer where changes are selected and reviewed before being permanently recorded in the repository history through a commit. This allows developers to group related changes and maintain controlled, intentional updates.

This supports Operational Excellence by enabling granular control over the content of commits, improving change management, traceability, and overall code quality.

      # Stages the specified file(s) for the next commit.
       git add index.html

First Commit Snapshot

Record your staged changes as a new commit in the local Git repository.

A commit creates a permanent snapshot of the files currently in the staging area and stores it in Git's version history. Each commit serves as a checkpoint, allowing you to track progress, review changes, and revert to previous versions if necessary.

This supports Reliability by maintaining a complete and traceable history of project changes, enabling effective version control and recovery.

1. Commit with Message

Creates a Git commit, which packages all staged changes into a commit object identified by a unique hash and accompanied by a descriptive commit message.

A commit acts as a permanent snapshot of your project's state at a specific point in time. These snapshots provide a reliable history of changes, making it possible to review progress, compare versions, and revert to a known working state if issues arise later.

This supports Reliability by enabling point-in-time recovery, preserving historical records, and ensuring traceability throughout the software development lifecycle.

      # Creates a new commit with all staged changes and the message after -m.
      git commit -m "Create index.html with Vim"

Establishing the Cloud Link

Connect your local Git repository to a remote repository hosted on GitHub.

This establishes a link between your local development environment and the remote repository, enabling you to synchronize code, share changes with collaborators, and back up your project to a centralized version control platform.

This supports Operational Excellence by facilitating collaboration, maintaining a single source of truth for the codebase, and ensuring changes can be reliably distributed across development teams and environments.

1. Add Remote Origin

Associates the remote alias origin with the URL of your GitHub repository.

Git is a distributed version control system, which means local repositories operate independently. Before code can be shared or synchronized, you must explicitly define the remote destination where changes will be pushed and retrieved.

Using a named remote such as origin provides a convenient reference to the repository's URL, simplifying future push, pull, and fetch operations.

This supports Reliability by ensuring your source code is stored in a highly available remote repository, providing backup, version history preservation, and protection against local data loss.

      # Stages the specified file(s) for the next commit.
       git remote add origin https://github.com/your-username/your-repo.git

Publishing to the Global Stage

Push your local commits to a remote repository hosted on GitHub.

This operation transfers committed changes from your local Git history to the remote repository, synchronizing your local development state with the centralized codebase and making updates available to collaborators.

This supports Reliability by ensuring code is safely backed up in the cloud and Operational Excellence by enabling seamless collaboration and consistent version synchronization across environments.

1. Push to Remote

Transfers all commits from the local master branch to the remote repository labeled origin.

This operation publishes your local changes to the remote version control system, making your updates accessible to collaborators and enabling integration with services such as GitHub Pages for deployment and hosting.

This supports Operational Excellence by synchronizing the local development environment with the central source of truth, ensuring consistency, collaboration, and controlled distribution of code changes.

      # Uploads your local commits to the remote repository.
      git push origin main

Live Hosting: GitHub Pages

Deploy your static content to a publicly accessible web server.

This process publishes your HTML, CSS, and JavaScript files to a hosting environment, making them available over the internet for end users to access through a web browser.

This supports Operational Excellence by ensuring consistent, reliable delivery of application assets from development to production environments.

1. Enable GitHub Pages

Configures GitHub to publish the repository as a static website and generate a publicly accessible URL.

This enables GitHub Pages to serve your project directly from the repository, allowing you to showcase your application without provisioning or managing dedicated servers.

This supports Performance Efficiency by leveraging GitHub’s globally distributed infrastructure (CDN), ensuring fast, low-latency content delivery to users across different regions.

      # 1. In GitHub UI: Settings -> Pages
      # 2. Source: 'Deploy from a branch'
      # 3. Branch: 'master' (or 'main')
      # 4. Folder: '/ (root)'
      # 5. Save

Automated Lifecycle: CI/CD

Defines a GitHub Actions workflow to automate the software deployment process.

This enables continuous integration and continuous deployment (CI/CD) by executing predefined steps such as building, testing, and publishing whenever changes are pushed to the repository, reducing manual intervention and improving consistency.

This supports Operational Excellence by automating repetitive tasks, improving deployment reliability, and ensuring faster, more consistent delivery of updates.

1. Create Workflow Definition

Creates the standard directory structure required for GitHub Actions workflows.

GitHub automatically detects and executes automation scripts only when they are placed inside the .github/workflows directory, where workflow configuration files are defined.

This supports Operational Excellence by enforcing a consistent and standardized location for automation pipelines, improving maintainability, discoverability, and reliability of CI/CD processes.

      # Creates a new directory (folder).
      mkdir -p .github/workflows

      # Creates an empty file or updates the timestamp of an existing one.
      touch .github/workflows/deploy.yml

Configure the Pipeline

Defines an automated workflow consisting of sequential jobs such as Checkout, Configuration, Build/Upload, and Deployment that are triggered on every push event to the master branch.

This CI/CD pipeline automates the software delivery process, reducing reliance on manual deployment steps, minimizing human error, and ensuring that the production environment consistently reflects the latest committed code.

This supports Reliability by enabling consistent, repeatable, and error-resistant deployments through automation.

      name: Deploy to Pages
      on:
        push:
          branches: [ master ]
      permissions:
        contents: read
        pages: write
        id-token: write
      jobs:
        deploy:
          environment:
            name: github-pages
          runs-on: ubuntu-latest
          steps:
            - uses: actions/checkout@v4
            - uses: actions/configure-pages@v4
            - uses: actions/upload-pages-artifact@v3
              with:
                path: '.'
            - uses: actions/deploy-pages@v4

Git and GitHub are essential tools in modern software development and DevOps workflows. Understanding how to move code from a local machine to a GitHub repository establishes the foundation for more advanced practices such as Continuous Integration (CI), Continuous Delivery (CD), Infrastructure as Code (IaC), and collaborative software engineering.

Introduction to DevOps for Beginners.

lotanna obianefo — Wed, 10 Jun 2026 19:30:47 +0000

DevOps is a modern software engineering approach that combines software development (Dev) and IT operations (Ops) into a unified practice aimed at improving the speed, reliability, and quality of software delivery. It is not a tool or a job title, but rather a culture, set of practices, and automation-driven methodology that enables organizations to build, test, and release software more efficiently.

At its core, DevOps is about breaking down the traditional silos between development and operations teams. In older models, developers would write code and “throw it over the wall” to operations teams for deployment and maintenance. This separation often led to delays, miscommunication, and unstable releases.

To gain a practical understanding of DevOps, we will examine a real-world project that involves deploying a simple web application using modern DevOps tools and methodologies.

Arm Your Workstation

Every DevOps engineer relies on a core set of tools to build, test, and deploy applications efficiently. In this setup, we will install three essential tools: Git for version control, curl for transferring data over networks, and Docker for containerizing applications. Together, these tools form a foundational toolkit for modern DevOps workflows.

1. Update Your Local Development Environment

This step updates your system's package repository information and upgrades installed software to the latest available versions. Keeping your system up to date ensures you have the latest security patches, bug fixes, and compatibility improvements, reducing the likelihood of installation failures or unexpected issues when setting up new tools.

Maintaining an updated and healthy environment is a fundamental operational practice. It helps ensure system reliability, consistency, and readiness for development and deployment activities, forming a strong foundation for efficient DevOps workflows.

      winget upgrade --all

These commands are for windows operating systems

2. Install Git, Curl, and Docker

This step installs three essential tools used throughout modern software development and DevOps practices. Git for version control and collaboration, curl for transferring data and interacting with web services from the command line, and Docker for packaging and running applications in isolated, portable containers.

These tools form the foundation of many development, automation, and deployment workflows, making them indispensable for engineers working with cloud and DevOps technologies.

Equipping your environment with industry-standard tools enables efficient development, automation, troubleshooting, and deployment processes. Standardized tooling improves productivity, consistency, and reliability across the software delivery lifecycle, supporting operational excellence and best practices.

      winget install -e --id Git.Git

      winget install -e --id Docker.DockerDesktop

      winget install -e --id curl.curl

      docker --version

These commands are for windows operating systems

3. Configure Git with Your Identity

This step configures your Git identity by setting your username and email address. Git uses this information to label every commit you make, ensuring that all changes in a codebase are properly attributed to the correct developer.

Without this configuration, Git cannot associate commits with a user identity, which prevents proper tracking of changes and can block or invalidate contributions in collaborative repositories.

Defining a clear user identity in Git supports traceability and accountability across the software development lifecycle. It ensures that every change can be audited, reviewed, and attributed, which is essential for secure, compliant, and well-governed development practices.

      # Sets Git configuration (username or aliases, etc.).
      git config --global user.name "Your Name"

      # Sets Git configuration (email).
      git config --global user.email "you@example.com"

      # Displays all Git configuration settings that are currently applied to your Git environment.
      git config --list

4. Create a GitHub Repository

This step creates a remote repository on GitHub, providing a centralized location to store and manage your code in the cloud. A remote repository acts as a shared source of truth where your project is safely backed up, version-controlled, and accessible to collaborators.

In real DevOps environments, code is never kept only on a local machine. It is stored in remote repositories to enable team collaboration, trigger automated CI/CD pipelines, and ensure code is not lost due to local system failure.

Remote repositories are essential for enabling teamwork, transparency, and continuous integration in modern software delivery. They serve as the foundation for collaborative development workflows, automated deployments, and scalable DevOps practices.

      # 1. Go to https://github.com and sign in (or create an account if you don't have one)

      # 2. Click the '+' icon in the top-right corner → 'New repository'

      # 3. Name it: devops-lab1

      # 4. Leave it PUBLIC, do NOT add a README (we'll push our own code)

      # 5. Click 'Create repository'

      # 6. Copy the HTTPS URL — it will look like: https://github.com/YOUR-USERNAME/devops-lab1.git

Containerise the App

Develop a small application and package it inside a Docker container to ensure it runs consistently across any environment. Containerizing the application isolates it from system-level differences, making it portable, reproducible, and easy to deploy on any machine or cloud platform.

1. Create Your First App

This step initializes a local project directory, creates a simple Node.js application, tracks it using Git version control, and links the local repository to a remote GitHub repository. This ensures that all code changes are properly recorded, versioned, and synchronized with a central remote source.

From the beginning of development, integrating with GitHub ensures that your work is securely backed up, easily shareable, and ready for integration into CI/CD pipelines for automated testing and deployment.

Applying version control from the start establishes a reliable and traceable development workflow. It supports consistency, recoverability, and automation readiness, which are key principles of operational excellence in modern DevOps practices.

      # Creates a new directory (folder).
      mkdir devops-lab && cd devops-lab


      # Let's create an app.js file. The '>' symbol redirects the 'echo' text into the file.
      # ALTERNATIVE: You can just open a text editor (like VS Code or Notepad), create a new file called 'app.js', type 'console.log("Hello, DevOps!");' and save it!

      # Prints text to the terminal — also used to write to files with > or >>.
      echo 'console.log("Hello, DevOps!");' > app.js

      # Initializes a new Git repository in the current directory.
      git init

      # Lists, creates, or manages branches.
      git branch -M main

      # Stages all changed files for the next commit.
      git add . && git commit -m 'Initial commit'

      # Now connect your local repo to the GitHub repo you created in Mission 1
      # Replace YOUR-USERNAME with your actual GitHub username

      # Stages the specified file(s) for the next commit.
      git remote add origin https://github.com/YOUR-USERNAME/devops-lab1.git

      # Manages remote repository connections (origin, upstream, etc.).
      git remote -v

2. Build the Docker Container

This step involves creating a Dockerfile, which defines the instructions required to package an application into a Docker image, then building that image and running it as a container. This process standardizes how the application is built and executed across environments.

By containerizing the application, you ensure consistency between development, testing, and production environments. This eliminates environment-specific issues such as dependency mismatches or configuration differences, commonly referred to as “it works on my machine” problems.

Containerization improves system reliability by providing consistent, immutable runtime environments. This ensures applications behave predictably across all stages of deployment, reducing failures and improving confidence in releases.

      # Here, 'printf' prints formatted text and '>' saves it into a file called 'Dockerfile'.
      # ALTERNATIVE: Open your text editor, create 'Dockerfile', paste the 3 lines starting with FROM, COPY, and CMD, then save it.

      # Prints formatted text — more control than echo (like C's printf).
      printf 'FROM node:18-alpine\nCOPY app.js .\nCMD ["node","app.js"]\n' > Dockerfile

      # Builds a Docker image from the Dockerfile in the current directory. The -t flag tags it with a name.
      docker build -t devops-helloo .

      # Creates and starts a new container from the specified image.
      docker run --rm devops-helloo

Measure DORA Metrics

Learn the key performance indicators known as DORA metrics, which high-performing DevOps teams use to measure software delivery efficiency, stability, and overall engineering effectiveness. These metrics help evaluate and improve how quickly and reliably teams deliver changes to production.

1. Simulate a Super-Fast Deployment

This step creates an additional Git commit to simulate the process of delivering a new feature to a codebase. Each commit represents a versioned change, similar to how features are incrementally shipped in real software development workflows.

Frequent commits and deployments reflect a key DevOps performance indicator known as Deployment Frequency, which measures how often code changes are released into production. High-performing DevOps teams aim for frequent, small, and reliable deployments rather than large, infrequent releases.

Increasing deployment frequency demonstrates improved delivery speed and responsiveness. It supports agile development practices by enabling rapid iteration, faster feedback loops, and continuous delivery of value to users.

      # Make a quick change and commit it


      # Prints text to the terminal — also used to write to files with > or >>.
      echo 'v2' >> app.js

      # Stages all changed files for the next commit.
      git add . && git commit -m 'feat: bump to v2'

      # Shows the commit history. --oneline condenses each commit to one line, --graph shows branches visually.
      git log --oneline

Automate with a Robot Butler (Make)

Instead of repeatedly typing long and complex commands, you can create a Makefile to automate and simplify repetitive tasks. A Makefile defines a set of instructions that can be executed with a single command, improving efficiency, consistency, and reducing the chance of human error during development workflows.

1. Write the Automation Script (Makefile)

This step involves creating a Makefile that defines reusable shortcuts (such as build, run, and clean) to automate long and repetitive Docker and development commands. Instead of manually typing complex instructions, a Makefile allows you to execute them using simple, consistent commands.

This improves workflow efficiency by reducing manual effort, minimizing human errors, and ensuring that common tasks are executed in a standardized way across all environments.

Automation of repetitive development tasks is a key principle of operational excellence. By using Makefiles, developers improve consistency, productivity, and reliability, while freeing up time to focus on higher-value engineering work.

       # 'printf' writes our commands with literal tab characters (\t) to create a syntactically correct Makefile.
       # ALTERNATIVE SIMPLER WAY: Open a text editor, create a file named 'Makefile', and manually type the build, run, and clean sections. (Make sure to use real tabs for indentation, not spaces!)

       # Prints formatted text — more control than echo (like C's printf).
        printf 'build:\n\tdocker build -t devops-helloo .\nrun:\n\tdocker run --rm devops-helloo\nclean:\n\tdocker rmi devops-helloo\n' > Makefile

Test Your New Butler

This step executes the automation defined in your Makefile by running predefined shortcuts to build a Docker image, start the application container, and clean up unused resources. It validates that your automated commands work correctly and produce the expected results in a local environment.

Testing automation locally is a critical practice before applying it to production systems, as it helps identify errors early and ensures that build, run, and cleanup processes behave consistently.

Verifying automation ensures that workflows are predictable, repeatable, and error-free. This strengthens system reliability by reducing deployment failures and ensuring that automated processes behave consistently across different environments.

      make build

      make run

      make clean

Tag the Production Release

Assign a version number (tag) to your codebase using Git to mark a stable release point. This creates a clear reference for future deployments, enabling easier tracking, rollback, and release management in a controlled software development lifecycle.

1. Create a Release Tag

This step finalizes your code changes by committing any remaining work and applying a version tag (e.g., v1.0.0) to mark a stable release point in the Git history. Tags act as immutable references that identify specific states of the codebase, making it easier to track releases and manage deployments.

In a CI/CD pipeline, new version tags can automatically trigger build, test, and deployment processes, ensuring that only validated and stable versions are promoted to production environments.

Version tagging improves system reliability by creating clear, identifiable release points. This enables safe rollbacks, consistent deployments, and better traceability across the software delivery lifecycle.

      # Stages all changed files for the next commit.
      git add . && git commit -m 'feat: add Makefile automation'

      # Creates a tag (label) on a commit — typically used for release versions (v1.0, v2.0).
      git tag -a v1.0.0 -m 'First epic DevOps lab release!'

      # Shows the commit history. --oneline condenses each commit to one line, --graph shows branches visually.
      git log --oneline --decorate

2. Push Everything to GitHub

This step pushes all local Git commits and the version tag (e.g., v1.0.0) to a remote GitHub repository, synchronizing your local development history with a centralized version control system. This ensures that your code and release versions are securely stored and accessible in a shared environment.

In real DevOps workflows, code must live in a remote repository rather than only on a local machine. Pushing changes to GitHub enables collaboration across teams, provides reliable backup, and acts as a trigger point for CI/CD pipelines that automate testing, building, and deployment processes.

Publishing code to a remote repository is essential for enabling team-based development and automated delivery workflows. It ensures that changes are shared, traceable, and ready for continuous integration and deployment across environments.

      # Push all your commits to GitHub

      # Uploads your local commits to the remote repository.
      git push -u origin main


      # If you get an error about 'main', your default branch might be called 'master' — try:
      # git push -u origin master
      # Push your release tag too


      # Uploads your local commits to the remote repository.
      git push origin v1.0.0


      # Prints text to the terminal — also used to write to files with > or >>.
      echo ''


      # Prints text to the terminal — also used to write to files with > or >>.
      echo '  🎉 CONGRATULATIONS! 🎉'


      # Prints text to the terminal — also used to write to files with > or >>.
      echo '  ✅ v1.0.0 is tagged and pushed to GitHub!'


      # Prints text to the terminal — also used to write to files with > or >>.
      echo '  🌐 Check your repo at: https://github.com/YOUR-USERNAME/devops-lab'

      # Prints text to the terminal — also used to write to files with > or >>.
      echo ''

      # Prints text to the terminal — also used to write to files with > or >>.
      echo 'Next up: CI/CD Pipelines with GitHub Actions'


      # Prints text to the terminal — also used to write to files with > or >>.
      echo '================================================'

DevOps is a transformative approach that enables organizations to deliver software faster, more reliably, and at scale. By combining automation, collaboration, and continuous improvement, DevOps bridges the gap between development and operations, making it a cornerstone of modern cloud-native engineering practices.

Whether you are a developer, system administrator, or aspiring cloud engineer, understanding DevOps is essential for working in today’s technology landscape.

Getting Started with Azure Kubernetes Service (AKS).

lotanna obianefo — Fri, 01 May 2026 19:31:57 +0000

As organizations increasingly adopt microservices and cloud-native architectures, container orchestration platforms have become essential. Azure Kubernetes Service (AKS) is a fully managed Kubernetes offering from Microsoft that simplifies deploying, managing, and scaling containerized applications in the cloud.

AKS reduces the operational overhead of managing Kubernetes by handling critical control plane components while providing deep integration with Azure services.

Workspace Initialization

Set up a local repository using Git and link it to a remote repository on GitHub to systematically track, version, and manage changes to your project, enabling progress monitoring, collaboration, and recovery of previous states if needed.

1. Initialize Git Repository

Create a new project directory, initialize it as a repository using Git, and perform an initial commit with a README.md file to establish a baseline.

This is essential in cloud engineering because version control enables tracking of code and infrastructure changes, supports collaboration, and allows safe rollback to previous states.

It aligns with the Operational Excellence pillar of the AKS Well-Architected Framework, ensuring effective change management, traceability, and reliable deployment practices.

      # Creates a new directory (folder).
      mkdir my-cloud-project 

      # Changes the current directory.
      cd my-cloud-project 

      # Initializes a new Git repository in the current directory.
      git init 

      # Prints text to the terminal — also used to write to files with > or >>.
      echo "# Cloud project Repository" > README.md 

      # Stages the specified file(s) for the next commit.
      git add README.md 

      # Creates a new commit with all staged changes and the message after -m.
      git commit -m "Initial commit"

Setup & Prerequisites

Prepare your local development environment and install the Kubernetes command-line interface, kubectl, which is required to interact with and manage Kubernetes clusters by deploying applications, inspecting resources, and executing administrative commands.

1. Login and Set Variables

Authenticate with Microsoft Azure using the command-line interface and define reusable variables for key resources (such as cluster name, region, and resource group) to standardize configuration.

This approach reduces manual input errors, ensures consistency during resource provisioning, and improves repeatability across deployments.

It aligns with the Operational Excellence pillar of the AKS Well-Architected Framework, as using variables and CLI-based automation promotes efficient, reliable, and well-governed cloud operations.

      # Signs you in to your Azure account so you can run commands against your subscription.
      az login

      # Sets the shell variable RG so later commands can reference it with $RG.
      RG="aks-project-rg"

      # Sets the shell variable CLUSTER_NAME so later commands can reference it with $CLUSTER_NAME.
      CLUSTER_NAME="skill-aks-cluster"

      # Sets the shell variable LOCATION so later commands can reference it with $LOCATION.
      LOCATION="australiacentral"

2. Install Kubectl

Install the Kubernetes command-line tool, kubectl, which serves as the primary interface for communicating with the Kubernetes API server to deploy applications, manage cluster resources, and perform administrative tasks.

Properly initializing this essential tooling ensures consistent and reliable interaction with the cluster, aligning with the Operational Excellence pillar of the AKS Well-Architected Framework by promoting standardized, efficient, and error-resistant operations.

      # Runs the Azure CLI command "az aks install-cli" — see "az aks install-cli --help" for details.
      az aks install-cli


      # Runs a Kubernetes cluster management command.
      kubectl version --client

3. Create Resource Group

Create a resource group in Microsoft Azure to act as a logical container for all cluster-related resources. This is required because Azure mandates that resources are organized within resource groups for consistent management, access control, and cost tracking.

It supports the Reliability pillar of the Azure Well-Architected Framework by enabling structured lifecycle management, including deployment, updates, and deletion of resources as a single unit.

      # Creates a resource group called "$RG" — a logical container for all the Azure resources in this project.
      az group create --name $RG --location $LOCATION

Provision the AKS Cluster

Create a managed Kubernetes cluster using Azure Kubernetes Service (AKS) and configure a single system node pool, which hosts core Kubernetes components and system workloads required for cluster operation. This setup provides a stable foundation for running containerized applications while benefiting from automated cluster management, scaling, and maintenance handled by Azure.

1. Create the Cluster

Provision a managed Kubernetes cluster using Azure Kubernetes Service (AKS), which automatically creates the Kubernetes control plane and a worker node for running workloads.

This is important because AKS handles the complexity of managing control plane components such as the API server, scheduler, and etcd, allowing you to focus on deploying and scaling applications rather than maintaining infrastructure.

It also aligns with the Performance Efficiency pillar of the Azure Well-Architected Framework by offloading operational overhead to the cloud provider, enabling more efficient use of resources and faster deployment cycles.

      az aks create \
        --resource-group $RG \
        --name $CLUSTER_NAME \
        --node-count 1 \
        --generate-ssh-keys \
        --node-vm-size Standard_D2_v3

Connect to the Cluster

Configure your local kubectl environment to securely communicate with the Kubernetes cluster by downloading and storing the cluster credentials, API endpoint information, and authentication certificates in the local kubeconfig file. This setup enables authenticated and encrypted interaction with the cluster for managing workloads and resources.

1. Download Kubeconfig

Download the Kubernetes cluster credentials from Azure Kubernetes Service (AKS) and merge them into the local ~/.kube/config file, which stores cluster connection details and authentication settings for kubectl.

This configuration is required because kubectl uses the cluster API endpoint, certificates, and access credentials to securely authenticate and communicate with the Kubernetes API server.

This process also supports the Security pillar of the Azure Well-Architected Framework by enabling encrypted authentication and controlled access through certificates and Role-Based Access Control (RBAC).

      az aks install-cli
      az aks get-credentials --resource-group $RG --name $CLUSTER_NAME

2. Verify Connection

Use kubectl to list the worker nodes in the Kubernetes cluster and verify the status of the cluster API endpoint.

This validation step confirms successful end-to-end connectivity between your local environment and the cluster, ensuring that the control plane and worker nodes are operational and ready to receive workloads.

This aligns with the Reliability pillar of the Azure Well-Architected Framework by verifying the operational readiness and availability of the Kubernetes environment before deploying applications.

      kubectl get nodes
      kubectl cluster-info

Deploy Your First App

Deploy a simple NGINX application to the Kubernetes cluster using a Kubernetes Deployment resource, which defines the desired application state and automatically manages pod creation, scaling, and recovery to ensure the application remains available and operational.

1. Create the Deployment

Create a Kubernetes Deployment that defines the desired state of running two replicas of the NGINX container within the cluster.

This is important because Kubernetes Deployments continuously monitor the application state and automatically replace failed pods to maintain the specified number of running replicas.

This self-healing capability improves application availability and supports the Reliability pillar of the Azure Well-Architected Framework by ensuring automated recovery and consistent workload operation.

      kubectl create deployment nginx-app --image=nginx --replicas=2

2. View Resources

Use kubectl to monitor the rollout status of your application deployment and track the progress of updates being applied to the cluster.

This is important because it provides real-time visibility into whether new pods are being created successfully and whether the application has reached its desired operational state without errors.

Monitoring deployment rollouts supports the Operational Excellence pillar of the Azure Well-Architected Framework by improving observability, enabling faster troubleshooting, and ensuring reliable workload management.

      kubectl get deployments
      kubectl get pods

Expose to the Internet

Create a Kubernetes Service of type LoadBalancer to expose your application to external users by automatically assigning a public IP address and routing incoming internet traffic to the application pods running inside the cluster. This allows the application to be securely accessed from outside the Kubernetes environment.

1. Create LoadBalancer Service

Create a Kubernetes Service of type LoadBalancer in Azure Kubernetes Service (AKS) to automatically provision an Azure Load Balancer and route external traffic to the application pods running in the cluster.

This is necessary because Kubernetes pods are accessible only within the cluster by default, and a LoadBalancer service provides a stable public IP address and entry point for external client access.

This approach supports the Performance Efficiency pillar of the Azure Well-Architected Framework by leveraging cloud-native networking and scalable traffic distribution to efficiently handle inbound application requests.

      kubectl expose deployment nginx-app --type=LoadBalancer --port=80

2. Retrieve Public IP

Use kubectl to continuously monitor the Kubernetes Service until the EXTERNAL-IP field changes from to an assigned public IP address.

This process is necessary because the cloud provider requires time to provision and configure the external load balancer that exposes the application to the internet. Once assigned, the public IP address serves as the endpoint used to access the application from a web browser.

This supports the Operational Excellence pillar of the Azure Well-Architected Framework by enabling real-time visibility and dynamic tracking of infrastructure resource provisioning.

      kubectl get service nginx-app --watch

3. Test Access

Verify that the web server hosted in Azure Kubernetes Service (AKS) is accessible from the internet by testing connectivity through the application’s public endpoint.

This end-to-end validation confirms that the networking components including the Kubernetes Service, load balancer, and application pods are correctly configured and functioning as expected.

Performing this final connectivity check supports the Reliability pillar of the Azure Well-Architected Framework by ensuring the application is available and reachable

        curl http://<YOUR_EXTERNAL_IP>

Cleanup

Avoid Azure costs by deleting the resource group

      az group delete --name aks-project-rg --yes --no-wait

Conclusion

Azure Kubernetes Service (AKS) simplifies the deployment, management, and scaling of containerized applications by combining the power of Kubernetes with the reliability and scalability of Microsoft Azure. Throughout this guide, you learned the core fundamentals of AKS, including cluster creation, application deployment, service exposure, and workload management using Kubernetes tools such as kubectl.

Building a Complete CI/CD Pipeline with Node.js, Docker, and K8s.

lotanna obianefo — Tue, 03 Mar 2026 16:53:45 +0000

Modern software delivery demands speed, reliability, and scalability. Continuous Integration and Continuous Deployment (CI/CD) pipelines enable teams to ship code faster while maintaining high quality and operational stability. When combined with Node.js, Docker, and Kubernetes (K8s), CI/CD becomes a powerful system for building cloud-native, production-ready applications.

This article provides a complete technical walkthrough of designing and implementing a CI/CD pipeline.

Before starting, you need to install these tools on your machine.

Required Downloads:

Node.js (v18 or higher) - Current LTS: v20.x
Download from: https://nodejs.org/
Choose the LTS version (20.x as of 2025)
Verify installation: node --version and npm --version
Git - Latest stable version
Download from: https://git-scm.com/downloads
Choose your operating system version
Verify installation: git --version
Docker Desktop - Latest version
Download from: https://www.docker.com/products/docker-desktop/
Install and start Docker Desktop
Verify installation: docker --version and docker-compose --version
GitHub Account
Sign up at: https://github.com
You'll need this for hosting your code and CI/CD pipeline
VS Code
Download: https://code.visualstudio.com/

Verify Everything is Installed

Step 1: Set Up Git for Version Control

Configures Git on your machine so it knows who you are when you make commits and sets up proper project tracking.

One-time Git Configuration

     git config --global user.name "Your Name"
     git config --global user.email "you@example.com"
     git config --global init.defaultBranch main

To displays all Git configuration settings that are currently applied for your environment use the command git config --list

Create and Initialize Project

To create and initialize the project, first create a new directory, navigate into it, and ensure the directory is initialized with a local Git repository using the below commands.

     mkdir my-devops-project
     cd my-devops-project
     git init

Step 2: Build a Node.js Web App

Creates a web application using Node.js that can serve web pages and API endpoints.

Initialize Node.js Project
This command creates a package.json file that describes your project and manages dependencies.

      npm init -y

The -y flag automatically responds “yes” to all confirmation prompts during command execution.

Update package.json

This customizes the package.json with proper scripts and metadata for your DevOps project.

Create/edit package.json:

      {
        "name": "devops-project01",
        "version": "1.0.0",
       "description": "DevOps learning project with Node.js",
        "main": "app.js",
        "scripts": {
          "start": "node app.js",
          "test": "jest",
          "dev": "node app.js",
          "lint": "eslint ."
        },
        "keywords": ["devops", "nodejs", "docker"],
        "author": "lotanna",
        "license": "MIT",
        "engines": {
          "node": ">=18.0.0"
        },
        "devDependencies": {
          "jest": "^29.7.0",
          "eslint": "^8.57.0",
          "supertest": "^7.1.4"
        }
      }

Create Application File

To create the application file, use the touch command to generate app.js, then insert the required code, which defines the following functionalities and outlines.

HTTP server that listens on port 3000
Serves different endpoints (/, /health, /info, /metrics)
Includes security headers and proper error handling
Provides graceful shutdown capability
Exports the server for testing

Create app.js:

      // core modules
      const http = require("http");
      const url = require("url");

      // environment configuration
      const PORT = process.env.PORT || 3000;
      const ENVIRONMENT = process.env.NODE_ENV || "development";

      let requestCount = 0;

      // helper: send JSON responses
      function sendJSON(res, statusCode, data) {
        res.statusCode = statusCode;
        res.setHeader("Content-Type", "application/json");
        res.end(JSON.stringify(data, null, 2));
      }

      // helper: send HTML responses
      function sendHTML(res, statusCode, content) {
        res.statusCode = statusCode;
        res.setHeader("Content-Type", "text/html");
        res.end(content);
      }

      // helper: send Prometheus metrics
      function sendMetrics(res) {
        const mem = process.memoryUsage();
        const metrics = `
      # HELP http_requests_total Total HTTP requests
      # TYPE http_requests_total counter
      http_requests_total ${requestCount}

      # HELP app_uptime_seconds Application uptime in seconds
      # TYPE app_uptime_seconds gauge
      app_uptime_seconds ${process.uptime()}

      # HELP nodejs_memory_usage_bytes Node.js memory usage
      # TYPE nodejs_memory_usage_bytes gauge
      nodejs_memory_usage_bytes{type="rss"} ${mem.rss}
      nodejs_memory_usage_bytes{type="heapUsed"} ${mem.heapUsed}
      nodejs_memory_usage_bytes{type="heapTotal"} ${mem.heapTotal}
      nodejs_memory_usage_bytes{type="external"} ${mem.external}
      `;
        res.statusCode = 200;
        res.setHeader("Content-Type", "text/plain");
        res.end(metrics);
      }

      // main server
      const server = http.createServer((req, res) => {
        requestCount++;
        const timestamp = new Date().toISOString();
        const { pathname } = url.parse(req.url, true);

        // logging
        console.log(
          `${timestamp} - ${req.method} ${pathname} - ${
            req.headers["user-agent"] || "Unknown"
          }`
        );

        // CORS headers
        res.setHeader("Access-Control-Allow-Origin", "*");
        res.setHeader("Access-Control-Allow-Methods", "GET, POST, PUT, DELETE");
        res.setHeader("Access-Control-Allow-Headers", "Content-Type");

        // security headers
        res.setHeader("X-Content-Type-Options", "nosniff");
        res.setHeader("X-Frame-Options", "DENY");
        res.setHeader("X-XSS-Protection", "1; mode=block");

        // route handling
        switch (pathname) {
          case "/":
           sendHTML(
              res,
              200,
              `
      <!DOCTYPE html>
      <html>
      <head>
        <title>DevOps Lab 2025</title>
        <style>
          body { font-family: Arial, sans-serif; max-width: 800px; margin: 50px auto; padding: 20px; }
          .header { background: linear-gradient(135deg, #667eea 0%, #764ba2 100%); color: white; padding: 20px; border-radius: 8px; }
          .endpoint { background: #f8f9fa; padding: 15px; margin: 10px 0; border-radius: 5px; border-left: 4px solid #007bff; }
        </style>
      </head>
      <body>
        <div class="header">
          <h1>DevOps Lab 2025</h1>
          <p>Modern Node.js application with CI/CD pipeline</p>
        </div>
        <h2>Available Endpoints:</h2>
        <div class="endpoint"><strong>GET /</strong> - This welcome page</div>
        <div class="endpoint"><strong>GET /health</strong> - Health check (JSON)</div>
        <div class="endpoint"><strong>GET /info</strong> - System information</div>
        <div class="endpoint"><strong>GET /metrics</strong> - Prometheus metrics</div>
        <p>Environment: <strong>${ENVIRONMENT}</strong></p>
        <p>Server time: <strong>${timestamp}</strong></p>
        <p>Requests served: <strong>${requestCount}</strong> </p>
      </body>
      </html>`
            );
            break;

         case "/health":
             sendJSON(res, 200, {
              status: "healthy",
              timestamp,
              uptime: process.uptime(),
              environment: ENVIRONMENT,
              version: "1.0.0",
              node_version: process.version,
              requests_served: requestCount,
            });
            break;

          case "/info":
            sendJSON(res, 200, {
              platform: process.platform,
              architecture: process.arch,
              node_version: process.version,
              memory_usage: process.memoryUsage(),
              environment: ENVIRONMENT,
              pid: process.pid,
              uptime: process.uptime(),
            });
            break;

          case "/metrics":
            sendMetrics(res);
            break;

          default:
            sendJSON(res, 404, {
              error: "Not Found",
              message: `Route ${pathname} not found`,
              timestamp,
            });
        }
      });

      // graceful shutdown
      function shutdown(signal) {
        console.log(`\nReceived ${signal}, shutting down gracefully...`);
        server.close(() => {
          console.log("Server closed");
          process.exit(0);
        });
      }
      process.on("SIGTERM", () => shutdown("SIGTERM"));
      process.on("SIGINT", () => shutdown("SIGINT"));

      // start server
      server.listen(PORT, () => {
        console.log(`🚀 Server running at http://localhost:${PORT}/`);
        console.log(`Environment: ${ENVIRONMENT}`);
        console.log(`Node.js version: ${process.version}`);
      });

      // export for testing
      module.exports = server;

touch app.js

Install Dependencies

      # Install testing and development tools
      npm install --save-dev jest eslint supertest

      # Install all dependencies (creates node_modules folder)
      npm install

npm install --save-dev jest eslint supertest installs development-only tools for testing (Jest), code quality enforcement (ESLint), and HTTP/API testing (Supertest), and records them under devDependencies.

npm install installs all dependencies defined in package.json (both dependencies and devDependencies), creates the node_modules directory, and ensures version consistency using package-lock.json.

After running the code, you'll see:

A node_modules/ folder with all installed packages
A package-lock.json file that locks dependency versions

Step 3: Create Proper Tests

This step sets up automated testing so you can verify your application works correctly every time you make changes.

Create tests directory and test file

      # Create a folder for your tests
      mkdir tests

      # Create the main test file
      touch tests/app.test.js

Create test file

Copy this code into already created tests/app.test.js:

      const request = require('supertest');
      const server = require('../app');

      describe('App Endpoints', () => {
        afterAll(() => {
          server.close();
        });

        test('GET / should return welcome page', async () => {
          const response = await request(server).get('/');
          expect(response.status).toBe(200);
          expect(response.text).toContain('DevOps Lab 2025');
        });

        test('GET /health should return health status', async () => {
          const response = await request(server).get('/health');
          expect(response.status).toBe(200);
          expect(response.body.status).toBe('healthy');
          expect(response.body.timestamp).toBeDefined();
          expect(typeof response.body.uptime).toBe('number');
        });

        test('GET /info should return system info', async () => {
          const response = await request(server).get('/info');
          expect(response.status).toBe(200);
          expect(response.body.platform).toBeDefined();
          expect(response.body.node_version).toBeDefined();
        });

        test('GET /metrics should return prometheus metrics', async () => {
          const response = await request(server).get('/metrics');
          expect(response.status).toBe(200);
          expect(response.text).toContain('http_requests_total');
          expect(response.text).toContain('app_uptime_seconds');
        });

        test('GET /nonexistent should return 404', async () => {
          const response = await request(server).get('/nonexistent');
          expect(response.status).toBe(404);
          expect(response.body.error).toBe('Not Found');
        });
      });

Create Jest configuration

Create a jest.config.js file, add the required configuration content, and save the file.

      module.exports = {
        testEnvironment: 'node',
        collectCoverage: true,
        coverageDirectory: 'coverage',
        testMatch: ['**/tests/**/*.test.js'],
        verbose: true
      };

Step 4: GitHub Actions CI/CD Pipeline

This Creates an automated pipeline that runs tests and builds Docker images every time you push code to GitHub.

Create workflow directory

The .github/workflows directory is the local repository path where GitHub Actions workflows are defined and executed to manage CI/CD processes.

      # Create the GitHub Actions directory structure
      mkdir -p .github/workflows

Create CI/CD pipeline file

Create .github/workflows/ci.yml:

Now add the required configuration content and save the file.

      name: CI/CD Pipeline

      on:
        push:
          branches: [ main, develop ]
          tags: [ 'v*' ]
        pull_request:
          branches: [ main ]

      env:
        REGISTRY: ghcr.io
        IMAGE_NAME: ${{ github.repository }}

      concurrency:
        group: ${{ github.workflow }}-${{ github.ref }}
        cancel-in-progress: true

      jobs:
        test:
          name: Test & Lint
          runs-on: ubuntu-latest

          strategy:
            matrix:
              node-version: [20, 22]

          steps:
            - name: Checkout code
              uses: actions/checkout@v4

            - name: Setup Node.js ${{ matrix.node-version }}
              uses: actions/setup-node@v4
              with:
                node-version: ${{ matrix.node-version }}
                cache: 'npm'

            - name: Install dependencies
              run: npm ci

            - name: Run linting
              run: npm run lint

            - name: Run tests
              run: npm test

            - name: Security audit
              run: npm audit --audit-level=critical || echo "Audit completed with warnings"

       build:
          name: Build & Push Image
          runs-on: ubuntu-latest
          needs: test
          if: github.event_name == 'push'

          permissions:
            contents: read
            packages: write
            security-events: write

          outputs:
            image-tag: ${{ steps.meta.outputs.tags }}
            image-digest: ${{ steps.build.outputs.digest }}

          steps:
            - name: Checkout code
              uses: actions/checkout@v4

            - name: Set up Docker Buildx
              uses: docker/setup-buildx-action@v3
              with:
                platforms: linux/amd64,linux/arm64

            - name: Log in to Container Registry
              uses: docker/login-action@v3
              with:
                registry: ${{ env.REGISTRY }}
                username: ${{ github.actor }}
                password: ${{ secrets.GITHUB_TOKEN }}

            - name: Extract metadata
              id: meta
              uses: docker/metadata-action@v5
              with:
                images: ${{ env.REGISTRY }}/${{ env.IMAGE_NAME }}
                tags: |
                  type=ref,event=branch
                  type=ref,event=pr
                  type=semver,pattern={{version}}
                  type=semver,pattern={{major}}.{{minor}}
                  type=sha,prefix={{branch}}-
                  type=raw,value=${{ github.run_id }}
                  type=raw,value=latest,enable={{is_default_branch}}
                labels: |
                  org.opencontainers.image.title=DevOps Lab 2025
                  org.opencontainers.image.description=Modern Node.js DevOps application

            - name: Build and push Docker image
              id: build
              uses: docker/build-push-action@v5
              with:
                context: .
                platforms: linux/amd64,linux/arm64
                push: true
                tags: ${{ steps.meta.outputs.tags }}
                labels: ${{ steps.meta.outputs.labels }}
                cache-from: type=gha
                cache-to: type=gha,mode=max
                target: production

            - name: Run Trivy vulnerability scanner
              uses: aquasecurity/trivy-action@0.24.0
              with:
                image-ref: ${{ steps.meta.outputs.tags }}
                format: 'sarif'
                output: 'trivy-results.sarif'
                severity: 'CRITICAL,HIGH'
              continue-on-error: true

            - name: Upload Trivy scan results
              uses: github/codeql-action/upload-sarif@v3
              if: always() && hashFiles('trivy-results.sarif') != ''
              with:
                sarif_file: 'trivy-results.sarif'

        deploy-staging:
          name: Deploy to Staging
          runs-on: ubuntu-latest
          needs: build
          if: github.ref == 'refs/heads/develop'
          environment: staging

          steps:
            - name: Deploy to Staging
              run: |
                echo "🚀 Deploying to staging environment..."
                echo "Image: ${{ needs.build.outputs.image-tag }}"
                echo "Digest: ${{ needs.build.outputs.image-digest }}"
                # Add your staging deployment commands here (kubectl, helm, etc.)

        deploy-production:
          name: Deploy to Production
          runs-on: ubuntu-latest
          needs: build
          if: github.ref == 'refs/heads/main'
          environment: production

          steps:
            - name: Deploy to Production
              run: |
                echo "🎯 Deploying to production environment..."
                echo "Image: ${{ needs.build.outputs.image-tag }}"
                echo "Digest: ${{ needs.build.outputs.image-digest }}"
                # Add your production deployment commands here

Step 5: Dockerfile

This step defines the build instructions Docker uses to create a portable container image of the application, ensuring consistent execution across environments.

The Dockerfile performs the following functions:

Uses multi-stage builds for smaller image size
Installs curl for health checks
Creates a non-root user for security
Sets up proper file permissions
Configures health checks

Create Dockerfile:

Input these commands into the Dockerfile

      # Multi-stage build for optimized image
      FROM node:20-alpine AS dependencies

      # Update packages for security
      RUN apk update && apk upgrade --no-cache

      WORKDIR /app

      # Copy package files first for better caching
      COPY package*.json ./

      # Install only production dependencies
      RUN npm ci --only=production && npm cache clean --force

      # Production stage  
      FROM node:20-alpine AS production

      # Update packages and install necessary tools
      RUN apk update && apk upgrade --no-cache && \
          apk add --no-cache curl dumb-init && \
          rm -rf /var/cache/apk/*

      # Create non-root user with proper permissions
      RUN addgroup -g 1001 -S nodejs && \
          adduser -S nodeuser -u 1001 -G nodejs

      WORKDIR /app

      # Copy dependencies from previous stage with proper ownership
      COPY --from=dependencies --chown=nodeuser:nodejs /app/node_modules ./node_modules

      # Copy application code with proper ownership
      COPY --chown=nodeuser:nodejs package*.json ./
      COPY --chown=nodeuser:nodejs app.js ./

      # Switch to non-root user
      USER nodeuser

      # Expose port
      EXPOSE 3000

      # Health check with proper timing for Node.js startup
      HEALTHCHECK --interval=30s --timeout=10s --start-period=15s --retries=3 \
        CMD curl -f http://localhost:3000/health || exit 1

      # Use dumb-init for proper signal handling in containers
      ENTRYPOINT ["dumb-init", "--"]

      # Start application
      CMD ["npm", "start"]

Step 6: Essential Configuration Files

This creates configuration files that tell various tools what to ignore, how to behave, and what settings to use.

Create .dockerignore

Create .dockerignore:

Input these commands into .dockerignore and save.

      # =========================
      # Dependencies & Package Managers
      # =========================
      node_modules
      npm-debug.log*
      coverage
      .nyc_output

      # =========================
      # Environment Variables
      # =========================
      .env
      .env.local
      .env.*.local

      # =========================
      # Version Control
      # =========================
      .git
      .github

      # =========================
      # Logs
      # =========================
      logs
      *.log

      # =========================
      # Editor & IDE Files
      # =========================
      .vscode
      .idea
      *.swp
      *.swo

      # =========================
      # OS Files
      # =========================
      .DS_Store
      Thumbs.db

      # =========================
      # Testing & Tooling
      # =========================
      tests/
      jest.config.js
      .eslintrc*

      # =========================
      # Documentation
      # =========================
      README.md

Create .gitignore

Create .gitignore:

Input these commands into already created .gitignore and save.

         # ===============================
         # Dependencies
         # ===============================
         node_modules/
         npm-debug.log*
         yarn-debug.log*
         yarn-error.log*

         # ===============================
         # Runtime Data
         # ===============================
         pids
         *.pid
         *.seed
         *.pid.lock

         # ===============================
         # Coverage & Test Reports
         # ===============================
         coverage/
         .nyc_output/

         # ===============================
         # Environment Variables
         # ===============================
         .env
         .env.local
         .env.*.local

         # ===============================
         # Logs
         # ===============================
         logs/
         *.log

         # ===============================
         # IDE / Editor
         # ===============================
         .vscode/
         .idea/
         *.swp
         *.swo

         # ===============================
         # OS Files
         # ===============================
         .DS_Store
         Thumbs.db

Create environment template

Create .env.example:

Input these commands into already created .env.example and save

       # ===============================
       # Server Configuration
       # ===============================
       PORT=3000
       NODE_ENV=production

       # ===============================
       # Logging Configuration
       # ===============================
       LOG_LEVEL=info

Create ESLint configuration

Create .eslintrc.js:

Input these commands into already created .eslintrc.js and save.

      module.exports = {
        env: {
          node: true,
          es2021: true,
          jest: true
        },
        extends: ['eslint:recommended'],
        parserOptions: {
          ecmaVersion: 12,
          sourceType: 'module'
        },
        rules: {
          'no-console': 'off',
          'no-unused-vars': ['error', { 'argsIgnorePattern': '^_' }]
        }
      };

Step 7: Docker Compose for Development

This creates a Docker Compose file that makes it easy to run your application and any supporting services with a single command.

Create docker-compose.yml:

      version: '3.8'

      services:
        app:
          build: .
          ports:
            - "3000:3000"
          environment:
            - NODE_ENV=development
            - PORT=3000
          restart: unless-stopped
          healthcheck:
            test: ["CMD", "curl", "-f", "http://localhost:3000/health"]
            interval: 30s
            timeout: 10s
            retries: 3
            start_period: 10s

Step 8: Test Everything Locally

This shows you how to actually run and test your application locally before deploying it.

Install and Test Locally

      # Install all dependencies from package.json
      npm install
      # Run your test suite to make sure everything works
      npm test
      # Start the application server
      npm start

Tests should pass with green checkmarks: ✓ GET / should return welcome page

Server starts and shows: 🚀 Server running at http://localhost:3000/

Test endpoints (in a new terminal window):

      curl http://localhost:3000/         # Homepage
      curl http://localhost:3000/health   # Health check JSON
      curl http://localhost:3000/info     # System info JSON  
      curl http://localhost:3000/metrics  # Prometheus metrics

Docker Commands

      # Build image
      docker build -t my-devops-app:latest .

      # Run container
      docker run -d \
        --name my-devops-container \
        -p 3000:3000 \
        --restart unless-stopped \
        my-devops-app:latest

      # Check container status
      docker ps
      docker logs my-devops-container

      # Test health check
      curl http://localhost:3000/health

      # Stop container
      docker stop my-devops-container
      docker rm my-devops-container

Build image

Run container

Check container status

Test health check

Stop container

Docker Compose Commands
Docker compose is not used to test in production environment but locally.

      # Start all services defined in docker-compose.yml
      docker-compose up -d

      # View real-time logs from all services
      docker-compose logs -f

      # Stop all services and clean up
      docker-compose down

Start all services defined in docker-compose.yml

View real-time logs from all services

Stop all services and clean up

Step 9: Deploy to GitHub
This commits your code to Git and pushes it to GitHub so the automated CI/CD pipeline can start working.

Initial commit

      # Add all files to Git staging area
      git add .

      # Create your first commit with a descriptive message
      git commit -m "Initial commit: Complete DevOps setup with working CI/CD"

Connect to GitHub

Before running these commands:

Go to GitHub.com and create a new repository called my-devops-project
DO NOT initialize it with README, .gitignore, or license (we already have these)
Copy the repository URL from GitHub

Replace YOUR_GITHUB_USERNAME below with your actual GitHub username

   # Set main as the default branch
   git branch -M main

   # Connect to your GitHub repository (UPDATE THIS URL!)
   git remote add origin https://github.com/YOUR_GITHUB_USERNAME/my-devops-project.git

   # Push your code to GitHub for the first time
   git push -u origin main

Your code appears on GitHub, and the CI/CD pipeline starts running automatically.

Step 10: Kubernetes Deployment Configurations
This step creates Kubernetes configuration files that define how your application should run in staging and production environments.

Create directories

       # Create directories for Kubernetes configurations
       mkdir -p k8s/staging k8s/production

Create Staging Deployment
Create k8s/staging/deployment.yml

      apiVersion: apps/v1
      kind: Deployment
      metadata:
        name: devops-app-staging
        namespace: staging
      spec:
        replicas: 2
        selector:
          matchLabels:
            app: devops-app
            environment: staging
        template:
          metadata:
            labels:
              app: devops-app
              environment: staging
          spec:
            containers:
            - name: app
              image: ghcr.io/YOUR_GITHUB_USERNAME/my-devops-project:develop-latest
              ports:
              - containerPort: 3000
              env:
              - name: NODE_ENV
                value: "staging"
              - name: PORT
                value: "3000"
              livenessProbe:
                httpGet:
                  path: /health
                  port: 3000
                initialDelaySeconds: 30
                periodSeconds: 10
              readinessProbe:
                httpGet:
                  path: /health
                  port: 3000
                initialDelaySeconds: 5
                periodSeconds: 5
      ---
      apiVersion: v1
      kind: Service
      metadata:
        name: devops-app-service-staging
        namespace: staging
      spec:
        selector:
          app: devops-app
          environment: staging
        ports:
        - protocol: TCP
          port: 80
          targetPort: 3000
        type: LoadBalancer

Create Production Deployment
Create k8s/production/deployment.yml

      apiVersion: apps/v1
      kind: Deployment
      metadata:
        name: devops-app-production
        namespace: production
      spec:
        replicas: 3
        selector:
          matchLabels:
            app: devops-app
            environment: production
        template:
          metadata:
            labels:
              app: devops-app
              environment: production
          spec:
            containers:
            - name: app
              image: ghcr.io/YOUR_GITHUB_USERNAME/my-devops-project:latest
              ports:
              - containerPort: 3000
              env:
              - name: NODE_ENV
                value: "production"
              - name: PORT
                value: "3000"
              resources:
                requests:
                  memory: "128Mi"
                  cpu: "100m"
                limits:
                  memory: "256Mi"
                  cpu: "200m"
              livenessProbe:
                httpGet:
                  path: /health
                  port: 3000
                initialDelaySeconds: 30
                periodSeconds: 10
              readinessProbe:
                httpGet:
                  path: /health
                  port: 3000
                initialDelaySeconds: 5
                periodSeconds: 5
      ---
      apiVersion: v1
      kind: Service
      metadata:
        name: devops-app-service-production
        namespace: production
      spec:
        selector:
          app: devops-app
          environment: production
        ports:
        - protocol: TCP
          port: 80
          targetPort: 3000
        type: LoadBalancer

Step 11: Complete Deployment Workflow

This step shows you how to use the complete CI/CD pipeline with proper branching strategy for staging and production deployments.

Branch-based Deployment Strategy

develop branch → Automatically deploys to staging environment
main branch → Automatically deploys to production environment
Pull requests → Run tests only (no deployment)

Deploy Changes
Deploy to staging:

      # Create and switch to develop branch
      git checkout -b develop

      # Make your changes, then commit and push
      git add .
      git status
      git commit -m "Add new feature"
      git push origin develop

GitHub Actions automatically runs tests and deploys to staging.

Deploy to production:

      # Switch to main branch
      git checkout main

      # Merge changes from develop
      git merge develop

      # Push to trigger production deployment
      git push origin main

Monitor Deployments

You can execute this command to monitor the GitHub Actions workflow execution and verify the health status of the deployed application.

      # Check GitHub Actions status
      # Visit: https://github.com/YOUR_GITHUB_USERNAME/my-devops-project/actions

      # Check your container registry
      # Visit: https://github.com/YOUR_GITHUB_USERNAME/my-devops-project/pkgs/container/my-devops-project

      # Test your deployed applications (once you have URLs)
      curl https://your-staging-url.com/health      # Staging health check
      curl https://your-production-url.com/health   # Production health check

This project implements a production grade CI/CD pipeline for a containerized Node.js application using GitHub Actions, Docker, and Kubernetes, demonstrating end-to-end DevOps engineering practices. The application exposes health, metrics, and system endpoints with graceful shutdown handling for Kubernetes environments.

Mastering Git for Production: Branching, Merging & Squash Strategies Every Engineer Should Know

lotanna obianefo — Thu, 19 Feb 2026 12:23:27 +0000

Modern software development depends heavily on version control systems to manage code changes, support collaboration, and maintain stability. Git is the industry-standard distributed version control system that enables teams to work concurrently without overwriting each other’s progress.

Core to Git’s power are its branching and history management capabilities specifically branching, merging, squashing, and rebasing. Understanding these concepts is essential for maintaining a clean, traceable, and production ready codebase.

By the end of this article, engineers will understand how to:

Create branches to work safely
Merge branches using different strategies
Fix merge conflicts
Squash many commits into one
Push a complete project to GitHub

PROJECT SETUP -Part 1

1. Create Project Folder

      mkdir git-merge-lab

This creates a new, empty directory named git-merge-lab, establishing an isolated workspace that prevents interference with existing files and ensures a controlled environment for Git merge practice.

2. Enter the Folder

     cd git-merge-lab

This navigates the terminal session into the project directory, setting the folder as the current working environment.

Purpose:
Git operations are context-sensitive and can only be executed within an initialized repository or project directory.

Outcome:
All subsequent files, commits, and version control activities will be contained within this directory, ensuring organized project structure and traceability.

3. Initialize Git

      git init

This Initializes the directory as a Git repository by generating a hidden .git subdirectory that stores metadata, configuration settings, and the complete version history.

Purpose:
Repository initialization is required for Git to begin tracking file changes and managing version control.

Outcome:
The directory is now under Git management, enabling change tracking, staging, committing, and collaboration workflows.

4. Create README File

      echo "# Team Project" > README.md

This creates a README.md file and populates it with initial content.

Purpose:
Git requires at least one tracked file to generate a commit and establish version history within the repository.

Outcome:
The README.md file is present in the working directory but remains untracked until it is staged and committed to the repository.

5. Stage the File

      git add README.md

This stages the file for inclusion in the upcoming commit by adding it to the Git index.

Purpose:
Git only records changes that have been explicitly staged, allowing developers to control which modifications are captured in a commit.

Outcome:
README.md is now in the staging area and prepared to be committed to the repository history.

6. Commit the File

      git commit -m "Initial commit"

This creates a commit that captures a snapshot of the project state within the repository history.

Purpose:
Committing establishes a restore point, enabling version rollback and facilitating traceability if future changes introduce issues.

Outcome:
The repository now contains its initial commit, marking the first recorded version of the project.

7. Rename Branch to main

      git branch -M main

This renames the active branch to main, aligning it with modern repository naming conventions.

Purpose:
Most hosting platforms and enterprise workflows designate main as the default branch, promoting consistency across development environments.

Outcome:
The primary development branch is now labeled main, serving as the central integration point for future changes.

FAST-FORWARD MERGE -Part 2

8. Create Feature Branch

     git checkout -b feature-login

This creates a new Git branch and checks it out as the active working branch.

Purpose:
Feature development is isolated in dedicated branches to prevent instability in the main (or production) branch and to support controlled integration workflows.

Outcome:
The working directory is now tracking the feature-login branch instead of main, ensuring all subsequent commits apply only to this feature stream.

9. Add Feature File

      echo "Login page created" > login.txt

This creates a new source file associated with the login functionality.

Purpose:
This step represents the introduction of new application logic and simulates the implementation of a feature within the codebase.

10. Commit Feature

      git add login.txt
      git commit -m "Add login feature"

Purpose of both commands:
git add stages the modified file by placing it into the index, preparing it for version control tracking.

git commit records the staged changes into the repository history as a new snapshot.

Outcome:
The feature changes are now securely versioned and stored within the feature branch’s commit history.

11. Switch Back to Main

      git checkout main

This switches the working context back to the main branch.

Purpose:
In Git, merge operations are executed into the currently checked-out branch, so you must be on the target branch before initiating a merge.

12. Merge Feature (Fast-Forward)

      git merge feature-login

The main branch advances its pointer to incorporate the commits from the feature branch.

Purpose:
Since main has not diverged and contains no new commits since the branch was created, Git performs a fast-forward merge rather than generating an additional merge commit.

3-WAY MERGE (PARALLEL WORK) -Part 3

13. Create Profile Feature

     git checkout -b feature-profile
     echo "Profile page created" > profile.txt
     git add profile.txt
     git commit -m "Add profile feature"

This establishes an isolated development context that allows a new feature to be implemented independently, without impacting the stability or history of other branches.

Note;
git checkout main switches the working directory to the main branch, ensuring the new work is based on the latest stable code.

git checkout -b feature-settings creates a new branch named feature-settings from main and immediately switches to it. These isolates feature development from the main codebase.

echo "Settings page created" > settings.txt creates a new file called settings.txt and writes initial content to it, representing the implementation of the settings feature.

git add settings.txt stages the newly created file by adding it to the Git index, marking it for inclusion in the next commit.

git commit -m "Add settings feature" creates a commit that records the staged changes in the repository history with a descriptive message, capturing the initial implementation of the settings feature.

14. Create Settings Feature

      git checkout main
      git checkout -b feature-settings
      echo "Settings page created" > settings.txt
      git add settings.txt
      git commit -m "Add settings feature"

At this point, the codebase has diverged, with independent changes introduced on two separate branches, resulting in distinct commit histories.

15. Merge Profile

      git checkout main
      git merge feature-profile

This ensures the main branch is updated first with the profile feature, establishing it as the authoritative baseline before integrating additional feature work.

16. Merge Settings (3-Way)

      git merge feature-settings

Note;
Demonstrates familiarity with the Vim editor by entering a commit message within the Vim interface and exiting correctly using the Esc key followed by :wq to write and quit.

Git generates a merge commit that reconciles and combines the divergent commit histories from both branches.

Outcome:
The main and feature branches have progressed independently, resulting in non-linear histories that require an explicit merge commit to integrate their changes.

MERGE CONFLICT -PART 4

17. Bugfix Changes README

      git checkout -b bugfix-title
      echo "# Team Project Version 2" > README.md
      git add README.md
      git commit -m "Update title in bugfix"

18. Feature Also Changes README

      git checkout main
      git checkout -b feature-title-update
      echo "# Awesome Team Project" > README.md
      git add README.md
      git commit -m "Update title in feature"

19. Trigger Conflict

      git checkout main
      git merge bugfix-title
      git merge feature-title-update

Git is unable to automatically complete the merge process and halts the operation.

Outcome:
Conflicting changes exist, and Git cannot determine which version should be applied, requiring manual conflict resolution by the developer.

20. Resolve Conflict

Open README.md delete the conflict marker and write the following command.

Note: Merge conflicts must be resolved manually by the developer. To do this, open the affected file in the Vim editor using vim README.md, review the conflict markers, and explicitly select or reconcile the appropriate changes.

      # Awesome Team Project Version 2

Then:

      git add README.md
      git commit -m "Resolve merge conflict"

This notifies Git that the merge conflict has been resolved and the finalized version of the file has been saved by staging the corrected file for commit.

SQUASH MERGE -PART 5

21. Create Feature With Many Commits & Squash It

      git checkout -b feature-dashboard

      echo "Dashboard layout" > dashboard.txt
      git add dashboard.txt
      git commit -m "Add dashboard layout"

      echo "Add charts" >> dashboard.txt
      git add dashboard.txt
      git commit -m "Add charts"

      echo "Fix alignment" >> dashboard.txt
      git add dashboard.txt
      git commit -m "Fix alignment"

Now squash:

      git checkout main
      git merge --squash feature-dashboard
      git commit -m "Add dashboard feature"

Squashing is used to consolidate multiple incremental development commits into a single, cohesive commit, ensuring that the main branch history remains clean, concise, and focused on meaningful changes rather than granular development steps.

22. View History

     git log --oneline --graph --all

This is to visually inspect and validate the type of merge performed, ensuring the resulting commit history aligns with the intended integration strategy.

PUSH TO GITHUB -PART 6

23. Create Repo on GitHub

A remote repository must be created and accessible prior to performing a push operation, as Git requires a valid remote endpoint to receive and store the local commits.

DO NOT check: Add README, Add .gitignore

24. Connect Local to GitHub

      git remote add origin https://github.com/YOUR_USERNAME/git-merge-lab.git

This defines the remote endpoint, informing Git of the destination repository to which local commits and branches should be transmitted.

25. Push All Branches

         git push -u origin --all

This Pushes all local branches (such as main, feature, and bugfix) to the remote GitHub repository and establishes upstream tracking relationships, enabling simplified and consistent push and pull operations in subsequent workflows.

Branching, merging, and squashing form the backbone of efficient Git workflows. Branching enables safe experimentation, merging integrates work and squashing keeps history readable. Mastering when and how to use each technique allows engineering teams to scale collaboration while maintaining a stable and maintainable codebase.

For modern DevOps environments where automation, rapid releases, and distributed teams are the norm these practices are not optional, they are foundational to high quality software delivery.

Get Started with Elastic Beanstalk

lotanna obianefo — Sat, 27 Dec 2025 15:01:28 +0000

Amazon Elastic Beanstalk (EB) is a Platform as a Service (PaaS) offering from AWS that simplifies the deployment, management, and scaling of web applications. It allows developers to focus on writing code while AWS handles infrastructure provisioning, load balancing, auto scaling, monitoring, and application health management.

Elastic Beanstalk is ideal for teams that want speed, scalability, and operational simplicity without sacrificing control over the underlying AWS resources.

To create an application

Search for Elastic Beanstalk on the search console and click on create Application.

The console provides a six-step process for creating an application and configuring an environment.

Step1: Configure Environment

In the Environment Tier section, select Web Server Environment.

Provide an Application Name (for example, Fintec_app25).
The system will automatically generate the corresponding Environment Name by appending _env to the application name.
Under the Platform configuration, select Node.js.
The recommended Platform Branch and Version will be automatically populated based on the selection.

Leave all other settings at their default values, then proceed by clicking Next.

Step 2: Configure Service Access

For the Service Role, select Create role if no existing role is available.

During the role creation process, leave all configuration parameters at their default values.
Proceed by clicking Next on both the Select trusted entity and Add permissions steps.
Update the Role name to a unique and descriptive identifier.
Complete the process by clicking Create role.

Just as the previous, For EC2 instance profile select Create role if no existing role is available.

During the role creation process, leave all configuration parameters at their default values.
Proceed by clicking Next on both the Select trusted entity and Add permissions steps
Update the Role name to a unique and descriptive identifier.
Complete the process by clicking Create role.

For the EC2 Key Pair, locate the service using the AWS Management Console search bar.

Create a new key pair by providing a unique and descriptive name.
Leave all other configuration options at their default settings.
Complete the process by selecting Create key pair.

Click Next on Configure service page afterwards.

Step3: Set up networking, database, and tags

Select the default VPC from the available options in the dropdown menu.
Enable Public IP address assignment for the instances.
From the Instance Subnet options, select any available subnet.

Leave all remaining parameters at their default values, then click Next to proceed.

Step4: Configure instance traffic and scaling

Select an existing EC2 Security Group from the dropdown list.
Leave all other configuration parameters at their default values, then click Next to continue.

Step5: Configure updates, monitoring, and logging

Select the appropriate CloudWatch metrics instance and the corresponding CloudWatch metrics environment from their respective fields simultaneously
Leave all other configuration parameters at their default values, then click Next to continue.

Now review the entire steps and click create.

Once the Environment is successfully lunched and the health status shows green and OK. Click the URL link listed for Domain to browse your application.

To access the Elastic Beanstalk–managed EC2 instance shell, navigate to Amazon Elastic Compute Cloud (EC2) and select the relevant Instance ID.
From the Instance Overview page, click Connect, then select Connect again to initiate an in-browser SSH session.

Amazon Elastic Beanstalk strikes a balance between simplicity and control. It abstracts infrastructure management while still allowing developers to customize and scale their applications using familiar AWS services.

For teams seeking fast deployments, built-in scaling, and reduced operational overhead, Elastic Beanstalk remains a powerful and reliable choice.

Prepare your app deployment tools and resources

lotanna obianefo — Tue, 02 Dec 2025 02:40:32 +0000

Many companies are looking for ways to simplify and modernize their DevOps processes. In some cases, their teams already run containerized applications on Azure Kubernetes Service (AKS) but aren’t fully using its advanced features, such as custom service mesh and autoscaling. To reduce complexity and improve efficiency, Azure Container Apps offers a lighter, more scalable, and cost-effective alternative.

By switching to Azure Container Apps, teams can streamline how they deploy and manage containerized applications, cut down on DevOps overhead, and benefit from built-in autoscaling and scale-to-zero features to make better use of resources.

Setup the environment
Install Docker Desktop

Open your web browser and go to the Docker Desktop installation page https://docs.docker.com/desktop/install/windows-install/.

Make sure your computer meets the required system specifications and follow the instructions provided on the website to complete the Docker Desktop installation

Install the .NET Software Development Kit

Open a browser window and then navigate to the .NET download page. https://dotnet.microsoft.com/download.

select the latest Long-Term Support (LTS) version, Double-click the installation file to begin the installation process.
On the .NET SDK Installer window, select Install.

Install Visual Studio Code with Docker and Azure App Service extensions

Open a browser window and then navigate to: https://code.visualstudio.com. In the browser window, select Download for Windows or Mac.

The Download page for Visual Studio Code automatically detects your operating system. It displays the version to download for your operating system, such as Linux, macOS, or Windows.

Wait for the installer file to finish downloading, and then use a file explorer application to navigate to your computer’s downloads folder.
In your file explorer application, select and run the Visual Studio Code installer file.

You can install Visual Studio Code using either the User Installer or System Installer. The User Installer installs Visual Studio Code just for the current user, while the System Installer installs Visual Studio Code for all users. The User Installer is the recommended option for most users.

Select I accept the license agreement, and then continue following the online instructions to complete the installation.
Accept the default options during the remainder of the installation.
Ensure that you have Visual Studio Code open.
On the Activity bar, select Extensions.
In the Search Extensions in Marketplace textbox, enter C#

Entering "C#" filters the list of extensions to show only the extensions that have something to do with C# coding.

In the filtered list of available extensions, select the extension labeled "C# Dev Kit - Official C# extension from Microsoft" that's published by Microsoft.
To install the extension, select Install.

Wait for the installation to complete.

On the EXTENSIONS view, replace C# with docker.
In the filtered list of available extensions, select the extension labeled Docker that's published by Microsoft.
To install the extension, select Install.

Wait for the installation to complete.

On the EXTENSIONS view, replace docker with azure app service.
In the filtered list of available extensions, select the extension labeled Azure App Service that's published by Microsoft.
To install the extension, select Install.

Wait for the installation to complete.

Close Visual Studio Code.

Install Azure CLI and the containerapp extension

Complete the following steps install Azure CLI and the containerapp extension.

Open a browser window, and then navigate to: /cli/azure/install-azure-cli.
In the browser window, follow the instructions for installing/updating Azure CLI for your computer's operating system.

The current version of the Azure CLI is 2.65.0. For information about the latest release, see the release notes. To find your installed version and see if you need to update, run az version. You can run az upgrade to install the latest version.

Open a command line or terminal application, such as Windows Command Prompt.
Sign in to Azure using the az login command.
Follow the prompts to complete the authentication process.
Install the Azure Container Apps extension using the az extension add --name containerapp --upgrade command

Install Microsoft PowerShell

Complete the following steps to install Microsoft PowerShell.

Open a browser window, and then navigate to: /powershell/scripting/install/installing-powershell.
In the browser window, follow the instructions for installing/updating PowerShell for your computer's operating system.

Configure a Resource Group for your Azure resources

Complete the following steps to configure a resource group for your Azure resources.

Open a browser window, and then navigate to the Azure portal: https://portal.azure.com/
Ensure that your Azure account has permission to create resources and assign RBAC permissions. Check the RBAC role(s) assigned to your account before you continue.

The Contributor role isn't able to assign Azure RBAC permissions. We recommend using an account that has been assigned the Owner, Azure account administrator, or Azure co-administrator role for your Azure subscription.

On the top search bar of the Azure portal, in the Search textbox, enter resource group
In the search results, select Resource groups, and then select + Create.
On the Basics tab, configure the resource group as follows:

Subscription: Specify the Azure subscription that you're using

Resource group: Enter RG1

Region: Select Central US.

Select Review + create.

Once validation has passed, select Create.

Configure a Virtual Network and subnets

Complete the following steps to configure a Virtual Network and subnets.

Ensure that you have your Azure portal open in a browser window.
On the top search bar of the Azure portal, in the Search textbox, enter virtual network
In the search results, select Virtual networks.
Select Create virtual network.

On the Basics tab, configure your virtual network as follows:

Subscription: Specify the Azure subscription that you're using
Resource group name: Select RG1
Virtual network name: Enter VNET1
Region: Ensure that Central US is selected.

Select the IP addresses tab.
On the IP addresses tab, under Subnets, select default.

On the Edit subnet page, configure the subnet as follows:

Name: Enter PESubnet
Starting address: Ensure that 10.0.0.0 is specified.
Subnet size: Ensure that /24 (256 addresses) is specified.

Select Save.
On the IP addresses tab, select + Add a subnet.

On the Add a subnet page, configure the subnet as follows:

Name: Enter ACASubnet
Starting address: Ensure that 10.0.4.0 is specified.
Subnet size: Ensure that /23 (512 addresses) is specified.

Select Add.

Select Review + create.
Once validation has passed, select Create.

Wait for the deployment to complete.

Configure Service Bus

Complete the following steps to configure a Service Bus instance.

Ensure that you have your Azure portal open in a browser window.

On the top search bar of the Azure portal, in the Search textbox, enter service bus
In the search results, select Service Bus.
Select Create service bus namespace.
On the Basics tab, configure your Service bus namespace as follows:

Subscription: Ensure that the Azure subscription is selected.
Resource group name: Select RG1
Namespace name: Enter sb-az2003-LT.
Location: Ensure that Central US is selected.
Pricing tier: Select Basic.
Select Review + create.

Once the Validation succeeded message appears, select Create.

Wait for the deployment to complete.

Configure Azure Container Registry

Complete the following steps to configure a Container Registry instance.

Ensure that you have your Azure portal open in a browser window.

On the top search bar of the Azure portal, in the Search textbox, enter container registry
In the search results, select Container registries.
On the Container registries page, select Create container registry or + Create.
On the Basics tab of the Create container registry page, specify the following information:

Subscription: Ensure that the Azure subscription is selected.
Resource group: Select RG1.
Registry name: Enter acraz2003LT2025
Location: Ensure that Central US is selected.
SKU: Select Premium.

The name of your Registry must be unique. Also, the Premium tier is required for private link with private endpoints.

Select Review + create.
Select Create.

After the deployment has completed, open the deployed resource.
On the left-side menu, under Settings, select Networking.
On the Networking page, on the Public access tab, ensure that All networks is selected.

On the left-side menu, under Settings, select Properties.
On the Properties page, select Admin user, and then select Save

Create a WebAPI app and publish to a GitHub repository

Complete the following steps to create a WebAPI app and publish to a GitHub repository.

Open Visual Studio Code.
On the File menu, select Open Folder.
Create a new folder named AZ2003 in a location that is easy to find.

For example, create a folder named AZ2003 on the Windows Desktop.

On the Terminal menu, select New Terminal.

At the terminal command prompt, to create a new ASP.NET Web API project, enter the following command:

       dotnet new webapi --no-https

At the terminal command prompt, run the following dotnet CLI command:

      dotnet build

On the View menu, select Command Palette, and then run the following command:

     .NET: Generate Assets for Build and Debug.

If the command generates an error message, select OK, and then run the command again.

In the root project folder, create a .gitignore file that contains the following information:
```
  [Bb]in/
  [Oo]bj/
```
On the File menu, select Save All.
Open the Source Control view.
Select Publish to GitHub.
If prompted, to enable the GitHub extension to sign in using GitHub, select Allow, and then provide authorization in GitHub.
In Visual Studio Code, select Publish to GitHub public repository.
Ensure that the bin and obj folders are not included in the repository.

Create Docker image and push to Azure Container Registry

Complete the following steps to create a Docker image and push the image to your Azure Container Registry.

Ensure that you have your AZ2003 code project open in Visual Studio Code.
To create a Dockerfile, run the following command in the Command Palette: Docker: Add Docker Files to Workspace.

When prompted, specify the following information:

Application Platform: .NET ASP.NET Core.
Operating System: Linux.
Ports: 5000.
Docker Compose files: No.

At a terminal command prompt, run the following docker CLI command:

      docker build --tag aspnetcorecontainer:latest .

The syntax for the build command is: docker build --tag image name:image tag .

This command builds a container image that is hosted by Docker and accessible using the Docker extension for VS Code.

Wait for the Docker Build command to complete.

Open the Visual Studio Code Command Palette, and then run the following command: Docker Images: Push.

When the command runs, enter the following information:

Select the docker image name that you created: aspnetcorecontainer

Select the image tag that you created: latest

If you see a message stating that no registry is connected, select Connect Registry, and then enter the following information:

Registry provider: Select Azure. Follow the online instructions to verify your Azure account if needed.

Azure subscription: Select the Azure Subscription for this project.

Select your Azure Container Registry resource: acraz2003LT25oct

An image tag is generated: acraz2003LT12oct.azurecr.io/aspnetcorecontainer:latest

To push the image to your Container Registry, press Enter.

The following Docker command is executed:

      docker image push acraz2003cah12oct.azurecr.io/aspnetcorecontainer:latest

Wait for the image to be pushed to your Azure Container Registry.
Open the Source Control view and then Commit and Sync your file updates.

Configure Azure DevOps and a starter Pipeline

Complete the following steps to configure Azure DevOps and a starter Pipeline:

Open the Azure portal.

On the top search bar, in the Search textbox, enter devops
In the search results, select Azure DevOps organizations.
Select My Azure DevOps Organizations.
On the home page of your organization, in the lower-left corner of the page, select Organization settings.
On the left side menu under Security, select Policies.
Ensure that the Allow public projects policy is set to On.
Return to the home page of your organization.
To create a new project, select New project.
If you created a new organization, you may see the Create a project to get started page.

On the Create new project page, specify the following information:

Project name: Project1
Description: AZ-2003 project
Visibility: Public

On the Create new project page, select Create project.
On the left-side menu, select Repos.
Under Import a repository, select Import.
On the Import a Git repository page, enter the URL for the GitHub repository you created for your code project, and then select Import.

Your repository URL should be similar to the following example:

https://github.com/your-account/AZ2003

On the left-side menu, select Pipelines.
Select Create Pipeline.
Select Azure Repos Git.
On the Select a repository page, select Project1.
Select Starter pipeline.
Under Save and Run, select Save, and then select Save.

To rename the pipeline to Pipeline1, complete the following steps:

On the left-side menu, select Pipelines.
To the right of the Project1 pipeline, select More options, and then select Rename/move.
In the Rename/move pipeline dialog, under Name, enter Pipeline1 and then select Save.

Don't run the pipeline now. You will configure this pipeline during the project exercise.

Deploy a self-hosted Windows agent

For an Azure Pipeline to build and deploy Windows, Azure, and other Visual Studio solutions you need at least one Windows agent in the host environment.

Complete the following steps to deploy a self-hosted Windows agent:

Ensure that you're signed-in to Azure DevOps with the user account you're using for your Azure DevOps organization.
From the home page of your organization, open your user settings, and then select Personal access tokens.
To create a personal access token, select + New Token.
Under Name, enter AZ2003.
At the bottom of the Create a new personal access token window, to see the complete list of scopes, select Show all scopes.
For the custom designed scope, select Agent Pools (Read & manage) and Deployment Groups (Read & manage).
Ensure that all the other boxes are cleared.
Select Create.

On the Success page, to copy the token, select Copy to clipboard.

You will use this token when you configure the agent.
Ensure that you're signed into Azure DevOps as the Azure DevOps organization owner.
Select your DevOps organization, and then select Organization settings.
On the left side menu under Pipelines, select Agent pools.
If the Get the agent dialog box opens, skip to the next step.

If a list of Agent pools is displayed, complete the following steps:

To select the default pool, select Default.

If the Default pool doesn't exist, select Add pool, and then enter the following information:
Under Pool type, select Self-hosted.
Under Name, enter default
Select Create.

To open the pool that you just created, select default.
Select Agents, and then select New agent

On the Get the agent dialog box, complete the following steps:

Select the Windows tab.
On the left pane, select the processor architecture of the installed Windows OS version on your machine.
The x64 agent version is intended for 64-bit Windows, whereas the x86 version is intended for 32-bit Windows.
On the right pane, select Download.
Follow the instructions to download the agent.

Use File Explorer to create the following folder location for the agent:
C:\agents

Unpack the agent zip file into the directory you created.
Open PowerShell as an Administrator.
Navigate to the "C:\agents" directory, and then enter the following PowerShell command:
```
       .\config
```

Respond to the configuration prompts as follows:

Enter server URL: enter the URL for your DevOps organization. Enter authentication type (press enter for PAT) >: press Enter.
Enter personal access token >: Paste-in the personal access token that you copied to the clipboard earlier.
Enter agent pool (press enter for default): press Enter.
Enter agent name (press enter for YOUR-PC-NAME), enter az2003-agent
Enter work folder (press enter for _work) >: press Enter.
Enter run agent as service? (Y/N) (press enter for N) >: enter Y
Enter enable SERVICE_SID_TYPE_UNRESTRICTED for agent service (Y/N) (press enter for N) >: enter Y
Enter User account to use for the service (press enter for NT AUTHORITY\NETWORK SERVICE) >: press Enter.
Enter whether to prevent service starting immediately after configuration is finished? (Y/N) (press enter for N) >: press Enter.

A message informing you that the agent started successfully is displayed.

Now you're now ready to begin your project.

Manage revisions in Azure Container Apps

lotanna obianefo — Mon, 01 Dec 2025 02:04:26 +0000

Azure Container Apps includes a built-in revision management system that allows you to track, control, and roll back application updates with ease. Each time you deploy new code or update configuration settings, Azure Container Apps automatically generates a new immutable revision. These revisions enable precise traffic management, safe deployments, blue-green or canary release strategies, and quick rollback in case of failures. By leveraging revision modes, traffic-splitting, and version history, teams can maintain application stability while continuously delivering updates in a controlled and observable manner.

Set revision management to multiple

In the Azure portal, open your container app resource.

On the left side menu, under Application, select Revisions and replicas.
At the top of the Revisions and replicas page, select Choose revision mode.
To switch from single to multi-revision mode, select Confirm.
On the Revisions and replicas page, wait for the Revision Mode setting to update.

The Revision Mode will be set to Multiple after the update. Also, on the left-side menu, the section title changes from Application to Revisions.

Create a new revision with a v2 suffix

In the Azure portal, ensure that you have the Revisions and replicas page of your container app resource open.

At the top of the page, select + Create new revision.

On the Create and deploy new revision page, complete the following steps:

Name / suffix: Enter v2

Under Container image, select your container image. aca-az2003. Select Create. Wait for the deployment to be completed.

Configure labels on the revisions

On the left-side menu, under Settings, select Ingress.
If Ingress isn't enabled, select Enabled.
On the Ingress page, specify the following information:

Ingress traffic: select Accepting traffic from anywhere.

Ingress type: select HTTP.

Client certificate mode: ensure that Ignore is selected.

Transport: ensure that Auto is selected.

Insecure connections: ensure that Allowed is NOT checked.

Target port: enter 5000

IP Security Restrictions Mode: ensure that Allow all traffic is selected.

At the bottom of the Ingress page, select Save, and then wait for the update to complete.

On the left-side menu, under Revisions, select Revisions and replicas.
For the v2 revision, under Label, enter updated
For the other revision, enter current

At the top of the page, select Save.

Configure a traffic percentage on the revisions

Ensure that you have the Revisions and replicas page open.

For the v2 revision, under Traffic, enter 25 as the percentage.
For the other revision, under Traffic, enter 75 as the percentage.

At the top of the page, select Save.

Verify your work

Ensure that you have your Container App open in the Azure portal.

On the left-side menu, under Application, select Revisions and replicas.

Verify that your revisions are configured as follows:

Azure Container Apps uses a revision-based deployment model that creates a new immutable revision each time you update a container app’s configuration or container image. This enables safe, controlled rollouts without disrupting existing traffic. Revisions can be activated, deactivated, or rolled back as needed, allowing teams to test new versions, split traffic for gradual releases, and maintain high availability.

Configure continuous integration by using Azure Pipelines

lotanna obianefo — Thu, 27 Nov 2025 22:38:51 +0000

Continuous Integration (CI) enables development teams to automatically build, test, and validate application changes whenever code is committed to a repository. In Azure environments, Azure Pipelines provides a robust CI service that integrates seamlessly with platforms like GitHub and Azure Repos. By configuring CI with Azure Pipelines, teams can automate the process of building container images, run tests, and securely pushing updated images to Azure Container Registry (ACR). This automated workflow ensures consistent deployments, reduces manual errors, and supports a scalable DevOps lifecycle for applications running on Azure Container Apps.

Configure Pipeline1 to use the self-hosted agent pool

Open a browser window, navigate to https://dev.azure.com, and then open your Azure DevOps organization.
On your Azure DevOps page, to open your DevOps project, select Project1.
In the left-side menu, select Pipelines.
Select Pipeline1, and then select Edit.

To use the self-hosted agent pool, update the azure-pipelines.yml file as shown in the following example:

           trigger:
            - main

           pool:
           name: default

           steps:

Recall that the pool section specifies the agent pool to use for the pipeline. The name property specifies the name of the agent pool. In this case, the name is default, which is the pool you configured as a self-hosted agent pool.

Under Validate and save, select Save without validating.
Enter a commit message, and then select Save.

Configure Pipeline1 with an Azure Container Apps deployment task

Ensure that you have Pipeline1 open for editing.

On the right side under Tasks, in the Search tasks field, enter azure container
In the filtered list of tasks, select Azure Container Apps Deploy
Under Azure Resource Manager connection, select the Subscription you're using, and then select Authorize.

In the Azure portal tab, open your Container App resource, and then open the Containers page.

Use the information on the Containers page to configure the following Pipeline1 Task information:

Docker Image to Deploy: Registry/Image:Image tag
Azure Container App name: Name

Configure the following Pipeline1 Task information:

Azure Resource group name: RG1

On the Azure Container Apps Deploy page, select Add.

The Yaml file for your pipeline should now include the AzureContainerApps tasks as follows:

                 trigger:
                   - main
                 pool:
                   name: default
                 steps:
                   - task: AzureContainerApps@1
                     inputs:
                       azureSubscription: '<Subscription>(<Subscription ID>)'
                       imageToDeploy: '<Registry>/<Image>:<Image tag>' from Container App resource
                       containerAppName: '<Name>' from Container App resource 
                       resourceGroup: '<resource group name>'

Select Validate and save, and then select Save again to commit directly to the main branch.

You most likely have an indentation error. Review and correct the indentation to resolve the issue.

The contents of the YAML file must be formatted correctly, including indentation. If you encounter an error, review the YAML file and correct any indentation issues.

Navigate back to the main page of your pipeline.

Run the Pipeline1 deployment task

Ensure that you have Pipeline1 open in Azure DevOps.

On the Runs tab of the Pipeline1 page, select Run pipeline.
A Run pipeline page opens to display the associated job.
Select Run.

The Jobs section displays job status, which progresses from Queued to Waiting.

It can take a couple minutes for the status to transition from Queued to Waiting.

If a 'Permission needed' message is displayed ("This pipeline needs permission to access 2 resources before this run can continue"), select View and then provide the required permissions.

Monitor the status of the run operation and verify that the run is successful.

Verify your work

In this task, you examine your pipeline and container app to verify successful pipeline runs.

Ensure that you have Project1 open in Azure DevOps.

On the left side menu, select Pipelines, and then select Pipeline1.
The Runs tab displays individual runs that can be selected to review details.
Open your Azure portal, and then open your Container App.
On the left side menu, select Activity Log.
Verify that a Create or Update Container App operation succeeded as a result of running your pipeline.

Notice that the Event initiated by column on the right shows your Project1 as the source.

In summary, configuring continuous integration (CI) with Azure Pipelines enables automated building, testing, and deployment of containerized applications to Azure Container Apps. By integrating your source code repository with Azure Pipelines, each commit or pull request can automatically trigger a pipeline that builds the container image, pushes it to Azure Container Registry (ACR), and deploys the updated image to Azure Container Apps. This setup ensures consistent application delivery, reduces manual overhead, and improves deployment reliability. Using YAML-based pipelines also provides version-controlled build definitions, promoting repeatability and alignment with DevOps best practices.

Create and configure a container app in Azure Container Apps

lotanna obianefo — Thu, 27 Nov 2025 03:44:52 +0000

Creating and configuring a container app in Azure Container Apps involves deploying a containerized application into a fully managed, serverless environment designed for cloud-native workloads. Azure Container Apps abstracts away the need to manage Kubernetes clusters while still providing key capabilities such as autoscaling, revisions, traffic splitting, and secure integration with supporting services like Azure Container Registry.

In this process, you define the container image to run, configure environment settings such as ingress and scaling rules, and connect the app to the required resources and identities. This setup enables reliable, scalable, and efficient execution of microservices and event-driven applications without managing underlying infrastructure.

Create a container app that uses an ACR image

Open your Azure portal.

On the portal menu, select + Create a resource.
On the top search bar, in the Search textbox, enter container app
In the search results under Services, select Container Apps.
Select Create.
On the Basics tab, specify the following:

Subscription: Specify the Azure subscription that you're using.
Resource group: RG1
Container app name: aca-az2003
Region: Select the Region specified for VNET1 (Central US).

The container app needs to be in the same region/location as the virtual network so you can choose VNET1 for the managed environment. For this guided project, keep all of your resources in the region/location specified for your resource group.

Container Apps Environment: Select Create new.

On the Create Container Apps Environment page, select the Networking tab, and then specify the following:

Use your own virtual network: Select Yes.
Virtual network: Select VNET1.
Infrastructure subnet: ACASubnet.

If the ACASubnet subnet is not listed, open your virtual network resource, adjust the subnet address range to 10.0.2.0/23 and retry the steps to create the Container App.

On the Create Container Apps Environment page, select Create.
On the Create Container App page, select the Container tab, and then specify the following:

Use quickstart image: Ensure that this setting is not selected. If it is selected, uncheck this setting.
Name: Enter aca-az2003
Image source: Ensure that Azure Container Registry is selected.
Registry: Select your container registry.: acraz2003cah.azurecr.io
Image: Select aspnetcorecontainer
Image tag: Select latest

Select Review + create.

Once verification has Passed, select Create.

Wait for the deployment to complete.

Configure the container app to authenticate using the user assigned identity

On the Azure portal, open the Container App that you created.
Under Security, select Identity.
Select the tab for User assigned.
Select Add user assigned managed identity.
On the Add user assigned managed identity page, select uai-az2003, and then select Add.

Configure a connection between the container app and Service Bus

On the Azure portal, ensure that you have your Container App open.
Under Settings, select Service Connector (Preview).
Select Connect to your Services.
On the Create connection page, specify the following:

Service type: Select Services Bus.
Client type: Select .NET.

Select Next: Authentication.

On the Authentication tab, select User assigned managed identity.
Ensure that the correct subscription and user assigned managed identity are selected.

Subscription: The Azure subscription that you're using.
User assigned managed identity: uai-az2003

To change tabs, select Review + Create.

Once the Validation passed message appears, select Create.

Wait for the connection to be created.

It can take a minute before the Service Connector page updates with the new connection.

Configure HTTP scale rules

Ensure that your Container App is open in the portal.

On the left-side menu under Application, select Revisions and replicas.

Notice the Name assigned to your active revision.

On the left-side menu under Application, select Containers.
To the right of Based on revision, ensure that your active revision is selected.
At the top of the page, select Edit and deploy.

At the bottom of the page, select Next: Scale.

Configure the Min / max replicas as follows:

Set Min replicas: 0
Set Max replicas: 2
Under Scale rule, select + Add.

On the Add scale rule page, specify the following:

Rule name: Enter scalerule-http
Type: Select HTTP scaling.
Concurrent requests: Set the value to 10,000.

On the Add scale rule page, select Add.

On the Create and deploy new revision page, select Create.

Ensure that your new scale rule is displayed.

Verify your work

Now you have to verify that your configuration meets the specified requirements.

In the Azure portal, ensure that your Container App resource is open.
On the left-side menu, under Settings, select Deployment.
At the top of the page, ensure that the Continuous deployment tab is selected.

Verify that the expected Registry settings are reported:

Repository source: Azure Container Registry
Registry: the name of your Container Registry; acraz2003LT2025
Image: aca-az2003

Open your Container Apps Environment resource.

Verify that your Container App uses the proper subnet as follows:

On the Overview page, verify that Virtual Network is set to VNET1.
On the Overview page, verify that Infrastructure subnet is set to ACASubnet.

Verify that the targetService properties match the specified configuration.

To verify your HTTP scale rule, you would need to run testing software that's able to simulate 10,000 concurrent HTTP requests and ensure that container replicas are created.

Configure Azure Container Registry for a secure connection with Azure Container Apps

lotanna obianefo — Thu, 27 Nov 2025 00:57:38 +0000

Configuring Azure Container Registry (ACR) for a secure connection with Azure Container Apps is a crucial step in ensuring that your containerized applications are deployed safely and efficiently. This process involves setting up permissions and authentication so Azure Container Apps can securely pull container images from ACR without exposing credentials. By integrating ACR with managed identities or workload identities, teams can streamline deployments, improve security, and maintain a clean, automated DevOps workflow.

Configure a user-assigned managed identity

Open your Azure portal.
On the portal menu, select + Create a resource.
On the Create a resource page, in the Search services and marketplace text box, enter managed identity
In the filtered list of resources, select User Assigned Managed Identity.
On the User Assigned Managed Identity page, select Create.
On the Create User Assigned Managed Identity page, specify the following information:

Subscription: Specify the Azure subscription that you're using for this guided project.
Resource group: RG1
Region: Central US
Name: uai-az2003
Select Review + create.
Select Create.

Configure Container Registry with AcrPull permissions for the managed identity

In the Azure portal, open your Container Registry resource that was already create.
On the left-side menu, select Access Control (IAM).
On the Access Control (IAM) page, select Add role assignment.
Search for the AcrPull role, and then select AcrPull.

Note: This configuration can also be applied when assigning the AcrPush role.

Select Next.
On the Members tab, to the right of Assign access to, select Managed identity.
Select + Select members.
On the Select managed identities page, under Managed identity, select User-assigned managed identity, and then select the user-assigned managed identity created for this project.

For example: uai-az2003.

On the Select managed identities page, select Select.
On the Members tab of the Add role assignment page, select Review + assign.
On the Review + assign tab, select Review + assign.

Wait for the role assignment to be added.

Configure Container Registry with a private endpoint connection

Ensure that your Container Registry resource is open in the portal.

Under Settings, select Networking.
On the Private access tab, select + Create a private endpoint connection.
On the Basics tab, under Project details, specify the following information:

Subscription: Specify the Azure subscription that you're using for this project.
Resource group: RG1
Name: pe-acr-az2003
Region: Ensure that Central US is selected.
Select Next: Resource.

On the Resource tab, ensure the following information is displayed:

Subscription: Ensure that the Azure subscription that you're using for this project is selected.
Resource type: Ensure that Microsoft.ContainerRegistry/registries is selected.
Resource: Ensure that the name of your registry is selected.
Target sub-resource: Ensure that registry is selected.
Select Next: Virtual Network.

On the Virtual Network tab, under Networking, ensure the following information is displayed:

Virtual network: Ensure that VNET1 is selected
Subnet: Ensure that PESubnet is selected.
Select Next: DNS.

On the DNS tab, under Private DNS Integration, ensure the following information is displayed:

Integrate with private DNS zone: Ensure that Yes is selected.
Private DNS Zone: Notice that (new) privatelink.azurecr.io is specified.

Select Next: Tags and then Select Next: Review + create.

On the Review + create tab, when you see the Validation passed message, select Create.

Wait for the deployment to complete.

Verify your work
In this task, you verify that your configuration meets the specified requirements.

In the Azure portal, open your Container Registry resource.
On the Access Control (IAM) page, select Role assignments.
Verify that the role assignments list shows the AcrPull role assigned to the User-assigned Managed Identity resource.
On the left-side menu, under Settings, select Networking.
On the Networking page, select the Private access tab.
Under Private endpoint, select the private endpoint that you created.

For example, select per-acr-az2003

On the Private endpoint page, under Settings, select DNS configuration.
Verify the following DNS setting:
Private DNS zone: set to privatelink.azurecr.io.
On the left-side menu, select Overview.
Verify the following setting:
Virtual network/subnet: set to VNET1/PESubnet.

To securely deploy containerized workloads in Azure Container Apps, you must establish a protected connection to Azure Container Registry (ACR), where container images are stored.

This configuration ensures that only authorized resources can pull images from the registry.