Training/gpcdesre
1
0
Fork 0
Code Releases Activity

Taken sample test

Browse Source
This commit is contained in:
Alex Soul 2021-02-18 15:52:25 +00:00
parent 753053326c
commit 9fe2862c88
2 changed files with 25 additions and 23 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

48
Part_3.md
View File

@ -11,13 +11,13 @@ Google Cloud CI/CD Pipeline (GCP DevOps Engineer Track Part 3)
- 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
Costs of 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
- 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)
@ -53,11 +53,11 @@ Many many smaller changes instead of single large changes
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"_
_"Continuous Integration 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 day. 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"
- Ensure the updated codebase is at least functional. Not completely broken. - This is a "Quality Bar"
#### Understanding Continuous Delivery
@ -66,7 +66,7 @@ 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.
- Making a deployment a big deal is an unnecessary 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"
@ -78,7 +78,7 @@ If the new feature doesn't work perfectly, the worst case scenario is that at le
#### Understanding Continuous Deployment
What is C Deployment?
What is Continuous 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"_
@ -86,11 +86,9 @@ 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 updated 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?
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.
Because the risk of making any change is 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
@ -146,7 +144,7 @@ The CI Process - 5x Main components
- Report
- Release
CI Components - How to we make this work?
CI Components - How do we make this work?
- Single Shared code repository
- Single source of truth
@ -171,10 +169,12 @@ Developer (Commits) > Source Control (Cloud Source Repositories) > {Trigger Buil
### Cloud Source Repositories
#### Cloud Source Repository Concepts
| Fully Managed Private Git Repository | Build, test, deploy and debug code right away |
| Native GCP Integration | Integrate with Cloud Build, Cloud Functions, Cloud Operations (formerly Stackdriver) and more |
| Sync/mirror third party repos | One-way mirror from GitHub/Bitbucket to CSR |
| Powerful code search | Google search for your code |
| - | - |
| ------------------------------------ | --------------------------------------------------------------------------------------------- |
| Fully Managed Private Git Repository | Build, test, deploy and debug code right away |
| Native GCP Integration | Integrate with Cloud Build, Cloud Functions, Cloud Operations (formerly Stackdriver) and more |
| Sync/mirror third party repos | One-way mirror from GitHub/Bitbucket to CSR |
| Powerful code search | Google search for your code |
Development Environments and Cross-project access
@ -236,10 +236,11 @@ result: <h1 style="margin:20px auto;width:800px;">Welcome to the GCP DevOps cour
- Mirror external GitHub repo to CSR
- One-way sync from GitHub to CSR
- GitHub is primary 'source of truth'. CSR is 'read-only' copy
<br>
- Grant access to user in another project
- Note: Not possible in Cloud Playgrounds
- Note: Granting access as repo/non-project level = cannot view cross-project repo via interface
<br>
- One-way sync updates are normally very quick after an update to a source repo, but the sync can be forced by clicking on the gear icon and clicking 'sync from GitHub'
> Minimum scope (Source repository Writer role) to provide user permissions to clone/edit/commit a repo is by specifying the user at the repo level (clicking gear icon on repo -> Permissions). The user however cannot browse or discover the repo through the webUI, for that the user needs permissions at the project level. To discover add the user at the project level to IAM with "Source Repository Reader" role. This permissions will allow the user read permissions to every other repository within the project.
@ -266,7 +267,7 @@ Life of a Kubernetes Container Deployment (i.e. manual 'stuff' you must do)
- Do it all again!
> Google calls this..... "Infinite loop of Pain and Suffering"
- More manual actions = greate chance of human error
- More manual actions = greater chance of human error
- Increased toil
- SRE objective = reduce toil
- Toil = manual and repetitive work that should be automated
@ -391,9 +392,10 @@ Up to this point we are updating source code, then manually submitting to Cloud
- Create a trigger to automatically start build on code commit
- Use separate build file with specific Dockerfile path
<br>
- Demonstrate fully automated build with triggers
- Only manual action is to commit code, Cloud Build handles the rest
<br>
- Create triggers
Cloud Build > Triggers > Create Trigger (Name: trigger-build, Event: Push to a branch, Source: build-demo, Branch: master, Build Configuration: Cloud Build configuration file (yaml or json), and specify location e.g. root(/cloud_build/build-run/trigger-build.yaml) of the repo) > Create
@ -553,7 +555,7 @@ Purpose of CI/CD - Automate it!
CI creates and stores containers
CD deploys our containers
Where do we deplpy our containers?
Where do we deploy our containers?
- K8's!
- Full customization and control vs. other services

BIN
img/gcp_devops_pro_sample_questions.pdf Normal file
View File

Binary file not shown.