Continuous integration: Difference between revisions

Content deleted Content added
History: The article describes IMVU's continuous deployment, not integration.
Tags: Mobile edit Mobile web edit
No edit summary
Line 152:
* Implies that incomplete code should not be integrated which is counter to some developer's preferred practice<ref name=":1" />
* Safety and mission-critical development assurance (e.g., [[DO-178C]], [[ISO 26262]]) require documentation and review which may be difficult to achieve
 
== Best practices for cloud systems ==
The following practices can enhance productivity of [[CI/CD|pipelines]], especially in systems hosted in the [[Cloud computing|cloud]]: <ref>{{Cite book |title=Serverless Architectures on AWS |publisher=Manning |isbn=978-1617295423}}</ref><ref>{{Cite book |title=Pipeline as Code Continuous Delivery with Jenkins, Kubernetes, and Terraform |publisher=Manning |isbn=9781638350378}}</ref><ref>{{Cite book |title=Continuous Delivery Reliable Software Releases Through Build, Test, and Deployment Automation |isbn=9780321670229}}</ref>
 
* '''Number of Pipelines''': Small teams can be more productive by having one [[Repository (version control)|repository]] and one pipeline. In contrast, larger organizations may have separate repositories and pipelines for each team or even separate repositories and pipelines for each service within a team.
* '''Permissions''': In the context of [[CI/CD|pipeline-related]] permissions, adhering to the [[principle of least privilege]] can be challenging due to the dynamic nature of [[Software architecture|architecture]]. Administrators may opt for more permissive permissions while implementing compensating [[security controls]] to minimize the blast radius.
 
== See also ==