Finished part_2, moved into part_3
This commit is contained in:
Soulmanos
parent
8c456da503
commit
eb281a9226
194
Part_3.md
Normal file
194
Part_3.md
Normal file
@ -0,0 +1,194 @@
|
||||
Google Cloud CI/CD Pipeline (GCP DevOps Engineer Track Part 3)
|
||||
==============================================================
|
||||
|
||||
### Understanding Google Cloud CI/CD Pipelines
|
||||
|
||||
#### Big Picture
|
||||
|
||||
- Taking Code changes (deltas) and automatically shepherding them through the process to become a running system, that the users of that system can actually use.
|
||||
- CI/CD system is internal software that serves the purpose of managing other software (internal or external)
|
||||
- CI/CD deploying to Prod e.g. GCP
|
||||
- Continuously - Why? - We avoid a lot of problems when we do things continuously, or rather we get loads of problems when we don't do things continuously. Higher cost when things are done regularly
|
||||
- Error-Prone Humans
|
||||
|
||||
Costs or a software Project
|
||||
|
||||
43% in Testing
|
||||
- Cost of removing an issue goes up dramatically as the phases of the project continue
|
||||
33% Cost reduction from a good QA system
|
||||
70% of outages are due to changes in a live system
|
||||
At least 10% (lower bound) cost saving by implementing CI/CD
|
||||
|
||||
[Martin Fowler - Software Guru (Agile, Scrum CI/CD)](https://martinfowler.com/articles/continuousIntegration.html#BenefitsOfContinuousIntegration)
|
||||
|
||||
* _"break down the barries between customers and development"_
|
||||
* _"allows your users to get new features more rapidly"_
|
||||
* _"more rapid feedback on those features"_
|
||||
* _"more collaborative in the development cycle"_
|
||||
* _"dramatically easier to find and remove [bugs]"_
|
||||
* _"dramatically less bugs, both in production and in process"_
|
||||
* _"reduced risk"_
|
||||
|
||||
#### Relating SRE to CI/CD
|
||||
|
||||
Martin Fowler - _"Continuous Integration is a software development practice... [that] allows a team to develop cohesive software more rapidly"_ - Make better software - Faster!
|
||||
|
||||
Make Software Faster
|
||||
|
||||
- Efficiency
|
||||
- Not just efficiency
|
||||
- Changes how you interact
|
||||
|
||||
Make Better Software
|
||||
|
||||
- Feedback Loops
|
||||
- Other Stuff
|
||||
- Leads to "Faster"
|
||||
|
||||
_"I think the greatest and most wide ranging benefit of Continuous Integration is reduced risk"_
|
||||
|
||||
Many many smaller changes instead of single large changes
|
||||
|
||||
#### Understanding Continuous Integration
|
||||
|
||||
What is CI?
|
||||
|
||||
_"Continuous Integraion is a software development practice where members of a team integrate their work frequently, usually each person integrates at least daily - leading to multiple integrations per dat. Each integration is verified by an automated build (including test) to detect integration errors as quickly as possible"_
|
||||
|
||||
Purpose:
|
||||
|
||||
- Ensure the updated codebase is at least functinoal. Not completely broken. - This is a "Quality Bar"
|
||||
|
||||
#### Understanding Continuous Delivery
|
||||
|
||||
What is CD?
|
||||
|
||||
_"Continuous Delivery is a software development discipline where you build software in such a way that the software can be released to production at any time"_
|
||||
|
||||
- Can be a major event
|
||||
- Making a deployment a big deal is an unesscessary problem.
|
||||
- Ensure the updated codebase is at least as good as it used to be - so it is releasable
|
||||
- This is also a "Quality Bar"
|
||||
|
||||
Regression - When some functionality broke e.g. a bug specifically when something used to work but now doesn't.
|
||||
|
||||
**CD is all about preventing regressions**
|
||||
|
||||
If the new feature doesn't work perfectly, the worst case scenario is that at least it worked like it did before.
|
||||
|
||||
#### Understanding Continuous Deployment
|
||||
|
||||
What is C Deployment?
|
||||
|
||||
_"[A]utomatic deployment helps both speed up the process and reduce error. It's also a cheap option since it just uses the same capabilities that you use to deploy into test environments"_
|
||||
|
||||
Reducing Errors - Requires high quality
|
||||
|
||||
Purpose - Make the newly updated and validated codebase available to the users. This is automation of an action. Absolutely requires excellent automated testing in that continuous delivery stage.
|
||||
|
||||
|
||||
|
||||
Just because this newly update and validated codebase is available to the users, this does not always mean that the updated functionality will immediately be available to those end users. I would say, in fact, it's ideal if that new functionality is not made available by the deployment... sound strange? Why is this?
|
||||
|
||||
Because the risk of making any change is the larger when the known impact of that change is larger, then you should try to reduce the impact of the change instead. If you deployed the new code base and you know that there should be no visible impact on the users, then all of your metrics should actually show that right? The evidence of what your users are doing now should corroborate your story and not contradict it. That's just good science, and of course good science underpins good engineering.
|
||||
|
||||
**Feature Flags/toggles** - really valuable to this situation
|
||||
|
||||
Really valuable tool in toolbox. Feature flags/toggles are a powerful technique allowing teams to modify system behaviour without changing code. Now the point I'm trying to make, is if you can modify behaviour without modifying the code then you can also use these to modify code without modifying behaviour, and this is how you use them to manage risk. When you're doing something new, you build that new thing into the system, and you continuously integrate what you're doing, but to stop those unfinished changes of yours from breaking everyone else, you should put your changed functionality behind a feature flag. Make it so that the default behaviour is unchanged from how it was before you started making your changes. This means that you're not regessing any previous funtionality and you leave your feature flag defaulting to "off" until you are ready to have other people using your new thing, then you turn it on for them. And by doing this you can then manage the roll-out of the feature completely independently from the rollout of the changed code. In fact, your half finished feature will likely have been deployed several times already, but it won't have caused any problems because you managed its impact with a feature flag and each deployment would have gone through your full CI/CD pipeline to validate the quality is still there. But then, when you fully rolled out that new feature and everyone is using it and you're sure you don't want to roll it back then you can simply remove the feature flag to simplify your codebase to remove that little bit of technical debt.
|
||||
|
||||
_"If you deploy into production one extra automated capability you should consider is automated roll-back. Bad things do happen from time to time... Being able to automatically revert also reduces a lot of the tension of deployment, encouraging people to deploy more frequently and thus get new features out to users quickly"_
|
||||
|
||||
"We engineer both changes and change management systems to reduce risk, and efficiently build great software"
|
||||
|
||||
#### Bringing CI and CD (and CD) Together
|
||||
|
||||
### Continuous Integration on Google Cloud
|
||||
|
||||
#### GCP Continuous Integration Concepts
|
||||
|
||||
### Cloud Source Repositories
|
||||
|
||||
#### Cloud Source Repository Concepts
|
||||
|
||||
#### CSR Hands On - Initial Setup and Deploy to Cloud Functions
|
||||
|
||||
#### CSR Hands On - Mirror Github and Cross-Project Access
|
||||
|
||||
#### Hands On Lab - Migration Source Code to a Google Cloud Source Repository
|
||||
|
||||
#### Hands On Lab - Inteegrating Google Cloud Functions
|
||||
|
||||
### Cloud Build
|
||||
|
||||
#### Importance of Automation
|
||||
|
||||
#### Cloud Build Concepts
|
||||
|
||||
#### Cloud Build Access Control
|
||||
|
||||
#### Perspective: Access Control
|
||||
|
||||
#### Hands On - Prepare Cloud Build Environment
|
||||
|
||||
#### Hands On - Automate Build with Triggers
|
||||
|
||||
#### Best Practices for Build Performance
|
||||
|
||||
#### Hands On Lab - Establishing a CI/CD Pipeline with Google Cloud
|
||||
|
||||
#### Hands On Lab - Triggering a CI/CD Pipeline with Google Cloud Build
|
||||
|
||||
### Artifact Management with Container Registry
|
||||
|
||||
#### Container Registry and Artifact Registry
|
||||
|
||||
#### What is Artifact Management?
|
||||
|
||||
#### Container Registry Concepts
|
||||
|
||||
#### Container Registry Hands On
|
||||
|
||||
#### Milestone: Changing Gears
|
||||
|
||||
### Continuous Deployment/Delivery Overview
|
||||
|
||||
#### GCP Continuous Deployment Concepts
|
||||
|
||||
#### Importance of Deployment Automation
|
||||
|
||||
#### Deployment Models
|
||||
|
||||
#### Continuous Deployment Tools
|
||||
|
||||
### Spinnaker
|
||||
|
||||
#### Spinnaker Concepts
|
||||
|
||||
#### Hands On - Set Up Spinnaker
|
||||
|
||||
#### Hands On - Deploy Sample App/Pipeline
|
||||
|
||||
#### Milestone: Are We There, Yet?
|
||||
|
||||
### Securing the Deployment Pipeline
|
||||
|
||||
#### Managing Secrets
|
||||
|
||||
#### Container Analysis and Vulnerability Scanning
|
||||
|
||||
#### Binary Authorization
|
||||
|
||||
### Full Development Pipeline
|
||||
|
||||
#### Full CI/CD Demo - Concepts
|
||||
|
||||
#### Create Spinnaker Cluster
|
||||
|
||||
#### Create App Repositories and Pipelines
|
||||
|
||||
#### Deploy and Manage Application
|
||||
|
||||
#### Milestone: Continuity
|
||||
|
||||
#### Hands On Lab: Create a CI/CD Pipeline on Google Cloud with Spinnaker
|
||||
|
||||
Loading…
Reference in New Issue
Block a user