Overview In the previous post, I set up Harbor container registry, Argo Events, and Argo Workflows as the foundation of the IDP. This post covers integrating those components with ArgoCD and designing Helm chart-based project templates to turn them into an Internal Developer Platform (IDP) that can deploy projects from a single YAML file. What Is an Internal Developer Platform? What is an Internal Developer Platform (IDP)? ...
Overview In the previous post, we installed HashiCorp Vault to build a secure secrets management system. This post covers the foundational pieces I set up before the internal developer platform itself: Harbor container registry, Argo Events, and Argo Workflows. Foundation Components for the IDP For the IDP I had in mind, I first needed the following core components: Container Registry: A central repository for storing and distributing built container images, enabling self-management of images without depending on public registries like Docker Hub. Event Processing System: Responsible for detecting various events such as code changes in Git repositories and webhook receipts, and triggering subsequent tasks in response. Workflow Engine: An engine for defining and executing actual CI/CD tasks such as code building, test execution, and container image creation. GitOps Deployment System: A system that automatically synchronizes the desired state defined in Git repositories to the cluster. ArgoCD, which was installed in an earlier post in this series, handles this role. In this post, I set up the container registry, event processing system, and workflow engine using Harbor, Argo Events, and Argo Workflows. In the next post, I connect these pieces to ArgoCD and the project template structure so they start to behave like an actual IDP. ...
Docker Compose is a tool for defining and running multi-container Docker applications. It uses YAML files to configure services, lets you start the full stack with a single command, helps keep development and production environments consistent, and simplifies the management of complex container setups. Docker Compose Overview What is Docker Compose? Docker Compose is a tool for defining, running, and managing applications composed of multiple containers. It allows you to declaratively define services, networks, and volumes in a docker-compose.yml file and manage the entire application stack with a single command. ...
Packaging React applications as Docker containers keeps development and production environments consistent. It also fits naturally into CI/CD pipelines, lets you use the same image across deployment targets such as Kubernetes, AWS ECS, and Azure Container Instances, and makes it easier to create optimized production images through multi-stage builds and nginx-based static file serving. Containerizing React Applications Why Containerize React Apps? React is a client-side JavaScript application that, after building, is bundled into static files (HTML, CSS, JavaScript) and served through a web server. Using Docker containers ensures build environment consistency, enables deployment automation, and simplifies environment-specific configuration management. ...
GitOps is an operating model that uses Git as the single source of truth for declarative infrastructure and application state, then synchronizes that state to running systems automatically. The term was introduced by Alexis Richardson, CEO of Weaveworks, in 2017 and later gained broad traction in the cloud-native community. By extending familiar Git workflows such as pull requests, code reviews, and branching into operations, GitOps has become a core practice in modern DevOps, especially when paired with declarative platforms like Kubernetes. ...
History and Background of Branching Strategies The systematization of Git branching strategies began on January 5, 2010, when Dutch developer Vincent Driessen published his blog post “A successful Git branching model.” The Git Flow introduced in this article resonated strongly in software development environments that required systematic release management at the time. In 2011, GitHub’s Scott Chacon proposed a simpler model called GitHub Flow. Then in 2014, GitLab announced GitLab Flow, combining the advantages of both strategies. All three strategies continue to be widely used today depending on project characteristics. ...
The Birth and Evolution of DevOps DevOps officially took shape in 2008, when Belgian IT consultant Patrick Debois organized the first “DevOpsDays” conference. It was inspired by John Allspaw and Paul Hammond’s influential Velocity presentation, “10+ Deploys Per Day: Dev and Ops Cooperation at Flickr,” delivered that same year. At the time, development and operations teams in many organizations often worked toward conflicting goals. Development teams wanted to release new features quickly, while operations teams focused on maintaining system stability. Because of this misalignment, software deployments often happened only every few weeks or months, and each release became a painful event. ...
CI/CD stands for Continuous Integration and Continuous Delivery or Continuous Deployment. It refers to a set of practices that automate how code changes are built, tested, and deployed during software development. In modern software teams, CI/CD is a core part of DevOps because it helps developers integrate and release code more frequently and with less risk. As a result, teams can shorten release cycles and catch bugs earlier. History and Origins of CI/CD CI/CD emerged during the wave of software development methodology innovation in the 1990s. It began as one of the core practices of Extreme Programming (XP) and has continued to evolve ever since. ...