Skip to content

Commit 4cc0a14

Browse files
committed
added Licence and several page updates
Added Licence file Added new page on CALMS updated glossary page Signed-off-by: Scott McCarthy <scott.mccarthy@opencastsoftware.com>
1 parent 1984a1d commit 4cc0a14

3 files changed

Lines changed: 109 additions & 0 deletions

File tree

LICENSE.md

Lines changed: 21 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,21 @@
1+
MIT License
2+
3+
Copyright (c) [2022] [Scott McCarthy]
4+
5+
Permission is hereby granted, free of charge, to any person obtaining a copy
6+
of this software and associated documentation files (the "Software"), to deal
7+
in the Software without restriction, including without limitation the rights
8+
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
9+
copies of the Software, and to permit persons to whom the Software is
10+
furnished to do so, subject to the following conditions:
11+
12+
The above copyright notice and this permission notice shall be included in all
13+
copies or substantial portions of the Software.
14+
15+
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
16+
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
17+
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
18+
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
19+
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
20+
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
21+
SOFTWARE.

docs/the-basics/calms.md

Lines changed: 45 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,45 @@
1+
---
2+
title: CALMS
3+
summary: The CALMS framework is used as a means of assessing whether an organization is ready to adopt DevOps processes
4+
author: Scott McCarthy
5+
date: 22/08/20221
6+
7+
---
8+
9+
## CALMS (Culture, Automation, Lean, Measurement, Sharing)
10+
11+
The CALMS framework is used as a means of assessing whether an organization is ready to adopt DevOps processes, or how an organization is progressing in their DevOps transformation. It is based on the following five pillars:
12+
13+
- **Culture.** Before silos can be torn down, there needs to be a culture of shared responsibility, or at least a group of people devoted to establishing that culture in a grassroots type of way, with management approval and support.
14+
Automation. Similar to the technical practices centered around continuous delivery mentioned above, teams undertaking a DevOps transformation should be devoted to automating as many manual tasks as possible, especially with respect to continuous integration and test automation.
15+
16+
- **Lean.** Development teams are making use of lean principles to eliminate waste and optimize the value stream, such as minimizing WIP, making work visible, and reducing hand-off complexity and wait times.
17+
Measurement. The organization is devoted to collecting data on their processes, deployments, etc., in order to understand their current capabilities and where improvements could be achieved.
18+
19+
- **Sharing.** A culture of openness and sharing within and between teams (and enabled with the proper tools) keeps everyone working toward the same goals and eases friction with hand-offs when issues arise.
20+
Three key practices that help promote a virtuous cycle—positive outcomes that continue to be reinforced and strengthened as they are iterated on—as you mature DevOps in your organization. These three high-level concepts encompass, and when they’re tackled in order, a continuous, virtuous cycle can gradually gain momentum.
21+
22+
## They are the 3Cs: - Culture - Collaboration - Continuous Improvement
23+
24+
### Culture
25+
26+
Once again, culture is a broad term that can mean different things to different people. It is one of the foundational aspects of DevOps that other technical and management practices must be built upon to succeed.
27+
As Accelerate authors discuss, Ron Westrum’s culture typologies for organizations can range from pathological (power-oriented) to bureaucratic (rule-oriented) to generative (performance-oriented). A generative culture is one in which bridging between teams is encouraged, risks are shared, and failure leads to inquiry, rather than finger-pointing. Working toward these cultural paradigm shifts—and giving them time to take hold through practice—is an important first step.
28+
29+
### Collaboration
30+
31+
Once the groundwork of a generative culture is laid—one in which everyone feels safe enough to “put themselves out there,” experiment, admit failures, and try again without fear of punishment or shame—greater collaboration can begin to be unlocked within and among teams.
32+
33+
Empowered employees are more open to sharing and receiving feedback, and the more those actions are witnessed, the more others on the team will begin to emulate similar behaviors. Overall performance and shared goals begin to be prioritized over protecting oneself or one’s silo.
34+
35+
### Continuous Improvement
36+
37+
Finally, once the teams are collaborating well, with everyone taking personal responsibility for performance, the continuous improvement piece begins to take care of itself. Here is where leadership can continue to reinforce a learning culture as well, one where taking time outside of the usual job responsibilities to work on personal and organizational improvements is key to keeping this virtuous cycle’s momentum going.
38+
39+
## In conclusion…
40+
41+
Every organization will implement these concepts differently. For example, some may choose Kanban over Scrum as means of collaboration; some may prefer Circle CI over Jenkins for CI/CD. What’s important to realize is that, regardless of implementation details, decisions should be guided by and also reinforce the concepts of Culture, Collaboration, and Continuous Improvement.
42+
43+
### Resources
44+
45+
CLAMS Framework by Atlassian - [CALMS Framework | Atlassian](https://www.atlassian.com/devops/frameworks/calms-framework)

docs/the-basics/glossary.md

Lines changed: 43 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -68,6 +68,49 @@ Click on the following bookmarks to jump to a specific section:
6868

6969
## __C - Terms__
7070

71+
| Term | Definition |
72+
| :------------------------ | :------------------------------------------------------------------------------------------------------------------------------------ |
73+
| Cadence | Flow or rhythm of events |
74+
| CALMS Model | Considered the pillars of values of DevOps: Culture, Automation, Lean, Measurement, Sharing (as put forth by John Willis, Damon Edwards and Jez Humble). |
75+
| Canary Testing | A canary (also called a canary test) is a push of code changes to a small number of end users who have not volunteered to test anything. Similar to incremental rollout, it is where a small portion of the user base is updated to a new version first. THis subset, the canaries, then serve as the proverbial "canary in the coal mine". If something goes wrong then a release is rolled back and only a small subset of the users are impacted. |
76+
| Capacity Test | The purpose of the test is to determine if the EUT can handle expected loads such as number of users, number of sessions, aggregate bandwidth. |
77+
| Capture-Replay | Test cases are created by capturing live interactions with the EUT, in a format that can be replayed by a tool. e.g. Selenium |
78+
| Carrots | Positive incentives, for encouraging and rewarding desired behaviors. |
79+
| Change | Addition, modification or removal of anything that could have an effect on IT services (ITIL definition). |
80+
| Change Failure Rate | A measure of the time from a request for change to delivery of the change. |
81+
| Change Management | Process that controls all changes throughout their lifecycle (ITIL definition). |
82+
| Chaos Engineering | The disciple of experimenting on a software system in production in order to build confidence in the systems capability to withstand turbulent and unexpected conditions. |
83+
| Chapter Lead | A squad line manager in the Spotify model who is responsible for traditional people management duties, is involved in day to day work and grow individual and chapter competence. |
84+
| Chapters | A small family of people having similar skills and who work within the same general competency area within the same tribe. Chapters meet regularly to discuss challenges and areas of expertise in order to promote sharing, skill development, re-use and problem solving. ] |
85+
| ChatOps | An approach to managing technical and business operations (coined by GitHub) that involves a combination of group chat and integration with DevOps tools. Example tools include Atlassian HipChat/Stride, Microsoft Teams, Slack. |
86+
| Check-In | Action of submitting a software change into a system version management system. |
87+
| CI Regression TestA subset of regression test that are run immediately after a software components is built. Same as Smoke | |
88+
| Clear-Box | Same as Glass-Box Testing and White-Box Testing |
89+
| Cloud Computing | The practice of using remote servers hosted on the internet to host applications rather than local servers in a private datacenter. |
90+
| Cloud-Native | Native cloud application (NCA) are designed for cloud computing |
91+
| Cluster Cost Optimization | Tools like Kubcost, Replex, Cloudability use monitoring to analyze container clusters and optimize the resource deployment model |
92+
| Cluster Monitoring | Tools that let you know the health of your deployment environments running in clusters such as Kubernetes |
93+
| Clustering | A group of computers (called notes or members) work together as a cluster connected through a fast network acting as a single system |
94+
| Code Coverage | A measure of white box test coverage by counting code units that are executed by a test. The code unit may be a code statement, a code branch, or control path or data path through a code module. |
95+
| Code Quality | See also static code analysis, Sonar and Checkmarks are examples of tools that automatically check the seven main dimensions of code quality - comments, architecture, duplication, unit test coverage, complexity, potential defects, language rules |
96+
| Code Repository | A repository where developers can commit and collaborate on their code. It also tracks historical versions and potentially identifies conflicting versions of the same code. Also referred to as repository' or 'repo'. |
97+
| Code Review | Software engineers inspect each others source code to detect coding or code formatting errors. |
98+
| Cognitive Bias | Cognitive bias is a limitation in objective thinking that is caused by the tendency for the human brain to perceive information through a filter of personal experience and preferences: a systematic pattern of deviation from morn or rationality in judgement. |
99+
| Collaboration | People jointly working with others towards a common goal. |
100+
| Collaborative Culture | A culture that applies to everyone which incorporates an expected set of behaviors, language and accepted ways of working with each other reinforcement by leadership. |
101+
| Compatibility Test | Test with the purpose to determine if and EUT interoperates with another EUT such as peer-to-peer applications or protocols |
102+
| Configuration Management | CM is a systems engineering process for establishing and maintaining consistency of a products performance, functional, and physical attributes with its requirements, design, and operational information throughout its life. |
103+
| Conformance Test | The purpose of the test is to determine if an EUT complies to a standard. |
104+
| Constraint | Limitation or restriction; something that constrains. See also bottleneck |
105+
| Container | A way of packaging software into lightweight, stand-alone, executable packages including everything needed to run it (code, runtime, system tools, system,libraries, settings). |
106+
| Container Network Security | Used to prove that any app that can be run on a container cluster with any other app can be confident that there is no unintended use of the other app or any unintended network traffic between them. |
107+
| | |
108+
| | |
109+
| | |
110+
| | |
111+
112+
## __D - Terms__
113+
71114
| Term | Definition |
72115
| :------------------------ | :------------------------------------------------------------------------------------------------------------------------------------ |
73116
| | |

0 commit comments

Comments
 (0)