This video talks about some of the concepts around continuous deployment/delivery.
We've covered the basics of CI in the CICD equation. So what's CD? CD stands for Continuous Delivery. It's not quite as easy to figure out just from the name as CI was. Basically it's the same concept as CI but instead of intergrating your code, you're deploying it in an automated way. Environments are a core concept here. An environment is a standalone hardware and software stack that is capable of running your entire application and configured for a specific purpose. First lets focus on that word standalone. An environment must be independent from other environments, so if you share a database between multiple test systems, for example, they're really only a single environment. The second point is that an environment must be capable of running your entire application. If you have a test system that is capable of supportng a partial feature set, although it may be useful for testing, you can't really consider it a full environment in the Continuous Delivery system. Unless it's part of a stack that supports the entire application. The final point is that the environment is configured to a specific purpose, commonly broken down into these categories: Dev, QA, Staging, and Prod. The first environment is Dev. This is quite often a developer's laptop but it might be a Vagrant box running your stack or a cloud instance for each developer. Whatever the solution, ideally there will be only one dev environment per developer so they don't step on each other's toes. A dev environment is designed so that it can easily be repaired or replaced if broken. So if a developer accidentally gets a SQL query wrong, they should be able to quickly throw away their database and restore it from a backup. Depending on your app a dev environment might also be running with paired down settings for things like the database, since it generally only has to support one user. QA is the next level from dev. In a small company with just a couple of developers, you might be able to combine the first two and either do QA in the dev environment or development in the QA environment. QA is a shared environment, intended for testing not development. It's the environment where your CI system will be running acceptance tests, and where any manual testing will take place. It's important that QA be similar to the production environment but it doesn't need to be a perfect match. For example, you might have a lot of dummy data in the QA database as a result of tests that interact with the database. Also the code in QA will be frequently updated and changed and might be buggy or partially complete. Staging, I think is the one that confuses a lot of developers, but from an op's perspective it's critical. Staging is essentially a clone of production. It should match as closely as possible to your actual live production environment. This includes the data in the database. If it's reasonable and doesn't violate any data security policies or compliance, your staging database should be identical to production, built from an actual backup from that database. The code in staging should only change as part of the process in pushing a release to production. So you should only update staging when you think something is ready for release. The point of staging is to let you test something in production without releasing it into production. So you push a release to staging, run through your tests, and once everything passes you'll have some assurance that it won't break things in prod. If tests fail in staging, you've saved yourself an embarrassing outage that might have cost you customers. The last environment is the obvious one, production. These are your customer facing servers, the actual real environment where code is running. Of course this needs to be part of your CD pipeline because it's how you release new features, but you should also be doing automated testing in prod. Once a release is pushed to production, it's good to have a sanity check suite of tests so that you could catch any issues before customers notice them. A good CD system makes it simple to roll out releases and just as simple to roll them back if there's a problem. In CD, pipelines are largely the same as in CI. Jobs are executed in a pipeline, so that you can stop a process as soon as there's a failure without running the rest of the pipeline. With "Get Live" CD features, you can easily have different pipelines for each of your environment. The ideal behind code promotion is that your environment correlate to your branches and match your software development lifecycle. One version of this concept is called "Get Flow", I'll give a simple variation of that. QA and dev are places where feature branches can be developed and tested. Once there confirmed good, they can be merged to a long lived development branch, either Master or Develop. That branch is deployed to QA for testing and when it's confirmed good a business decision is made to release a specific set of changes. This is known as "cutting a release", and it involves pushing to a long running release branch and tagging with a release version. That code is released to staging for final testing and finally identical code as what's tested in staging is pushed to prod.
- Navigating the GitLab interface
- Using GitLab for collaboration
- Merging requests
- Continuous integration and continuous delivery
- Creating and running a pipeline
- Deploying a project using GitLab