- 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"
Running System --{Reflag}--> Released Feature --{Ask}--> Feedback --{Triage}--> Idea on Backlog --{Code (v.)}--> Code Change & Pull Request (PR) --{Approve}--> Return to "Codebase"
- Setup Cloud function, pointing to repository that we cloned making sure to specify the sub-directory where the python code is located, create the function and then call it from the cli
- GitHub is primary 'source of truth'. CSR is 'read-only' copy
- 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
- 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.
