This blog is a supplement to the CD 101, CD 102, and CD 103 blogs.
This blog is a supplement to the CD 101, CD 102, and CD 103 blogs. If you haven’t read them yet, I strongly recommend you do so! It’s an excellent introduction to the world of modern Continuous Delivery. I recap everything that I’ve learned since joining Harness and spoon feed you the fundamentals concepts and terms of CD to get you up and running with Harness.
In the least, you’ll have a basic understanding of what modern Continuous Delivery entails. Enjoy this outline for your reference as a supplement to your CD adoption journey!
Continuous Delivery Fundamentals
CI is the process of taking a developer’s code throughout the various steps necessary for it to be ready to be deployed as an application. Or, to be more accurate, an artifact (see artifact below). Read more.
CD is the process of taking an artifact throughout the various steps necessary for it to be deployed to customers into production. Specifically, the six major steps are: accessing clouds, provisioning infrastructure, change management and approvals, a release strategy, verification of the deployments (e.g. performance/quality) and rolling the software back in the event of a failure or anomaly/regression. Read more.
A service is self-contained software that represents a distinct business function, use case or task. Technically, it’s an individual run-time. For example. This can be a Dockerized container or simply a Node.js application. Read more.
An artifact is a packaged service/application code that has gone through a CI build process and is now ready for the CD process. Simply put, it is a service that is built, packaged, and ready for deployment. A simple example would be a docker container. Read more.
Continuous Delivery Pipelines
An environment is where you deploy your service or application to; they represent the target compute infrastructure (aka Clusters). Most dev teams have one or more environments (e.g, dev, QA, staging, production). Read more.
A pipeline is made up of one or more stages, a stage represents tasks and tests that an artifact must to go through and satisfy in order to proceed to the next stage. You can create and map stages by environments (e.g. dev, QA, staging, prod) or you can map them through functional tasks or tests (e.g. regression testing, performance testing, security testing).
A stage can also be a governance approval step that gates/govern how artifacts are promoted between environments. Read more.
Workflows typically automate three things: deploy the service, test/verify the service, and then rollback the service (if necessary). Basically, it’s all the stuff you have to do in order to complete that stage. If you’re in a Dev stage (e.g. Stage 1) you might have some security scans you want to complete. If you’re in a QA stage (e.g. Stage 2) you might have smoke, regression, or automated tests you want to run against the service. Read more.
Executing workflow steps in parallel that have no dependencies on each other. This is in contrast to steps that are sequential.
A popular example of this is deploying multiple services to multiple clusters or clouds within the same stage of a pipeline. This is common in microservice architectures. Read more.
A pipeline is a term to describe all of the stages (and their corresponding workflows) stitched together that relate to one or more services. Remember, each stage has a workflow. So, a pipeline stitches together stages and their corresponding workflows.
A pipeline is an umbrella term for all of the pieces working together. Read more.
A trigger is an event or condition that executes your pipeline. Read more.
The ability to automatically rollback your deployment if it fails a verification test or stage (see below, Continuous Verification). Read more.
Variables that are set and passed to your application throughout its lifecycle in a pipeline.
Harness variables come in two flavors:
- Harness built-in variables: There are variables scoped to different entities—such as Applications, Services, Environments, and Workflows—and variables that provide information about deployment environments.
- User-created variables: You can create variables at the account level and application level, which can be used across your Harness applications. You can also create variables in Application entities, to be replaced by users when configuring or deploying a CD pipeline.
You can read more here.
You can also pass variables from a Harness Trigger into a Harness Workflow to be used during Workflow steps or configuration or as part of a Pipeline. This process can be valuable when you want to use information from the condition that initiated the Trigger as settings in your Workflow at runtime. Read more.
Private and secure variables that are exposed to clouds, services or tools within a pipeline. Common examples include database access credentials and API tokens. Harness allows for the integration of existing secrets managers (e.g. Vault, KMS, Azure KeyStore etc.) or the ability to use the existing built-in secrets manager within Harness. Read more.
A release methodology that reduces risk and exposure to both customers and the business. Canary is a method of slowly releasing in small stages across nodes within your network before a full deployment. Read more.
A blue/green release is replicating a production environment and switching traffic between lives environments as each non-live environment receives the later update. Read more.
The painful, all-hands-on-deck, release process that companies utilize when they don’t have a proper CD solution in place and everything is done manually. Expect lots of sleep-loss, anxiety, and stress. Your kids won’t like you, either, when you’re in this stage. Read more.
When artifacts are promoted to an environment (e.g. dev, QA, staging or production), the performance/quality of that artifact must be tested and verified for a finite period of time to ensure the pipeline stage can proceed and complete. A modern CD platform will test artifacts immediately using data (metrics/events) from your existing performance and log tools and — if necessary — rollback the artifact.
For example, does the response time of end-user requests increase or decrease post-deployment? Does the service throw any new errors or exceptions post-deployment? Read more.
Using the same models as continuous verification, 24/7 Service Guard monitors your services/applications on a 24/7 continuous basis vs. a finite amount of time post-deployment. Read more.
Orchestrating continuous monitoring of services among major performance monitors
Get with the program
If you’re interested in Harness, sign up for a free-trial!