create web for devops-maturity spec (#1)

* create web for devops-maturity spec

* rename to DevOps Maturity

* update package-lock.json

* fix can not found issue

* save changes

* update backgroup and font color

Author: shenxianpeng

.github/CODEOWNERS

@@ -1 +1 @@
-* @conventional-branch/developers
+* @devops-maturity/developers

.github/dependabot.yml

@@ -3,7 +3,7 @@
 version: 2
 updates:
 - package-ecosystem: npm
-  directory: /themes/conventional-branch/
+  directory: /themes/devops-maturity/
   schedule:
     interval: monthly
   groups:

.github/workflows/main.yml

@@ -65,7 +65,7 @@ jobs:
         if: github.ref == 'refs/heads/main' && github.event_name != 'pull_request'
         with:
           personal_token: ${{ secrets.PERSONAL_TOKEN }}
-          external_repository: conventional-branch/conventional-branch.github.io
+          external_repository: devops-maturity/devops-maturity.github.io
           publish_branch: main
           user_name: 'github-actions[bot]'
           user_email: 'github-actions[bot]@users.noreply.github.com'

CONTRIBUTING.md

@@ -33,15 +33,15 @@ Once the website will be compiled, you can see the website visiting `http://loca
 
 ## Contributor Behavior
 
-Be kind to one another. We're striving to make Conventional Branch an inclusive environment that's great for first time open-source contributors.
+Be kind to one another. We're striving to make DevOps Maturity an inclusive environment that's great for first time open-source contributors.
 
 tldr; we value constructive community interaction, over technical acumen.
 
 ## Pull Requests
 
-Conventional Branch use the [GitHub flow](https://guides.github.com/introduction/flow/) as main versioning workflow
+DevOps Maturity use the [GitHub flow](https://guides.github.com/introduction/flow/) as main versioning workflow
 
-1. Fork the Conventional Branch repository
+1. Fork the DevOps Maturity repository
 2. Create a new branch for each feature, fix or improvement
 3. Send a pull request from each feature branch to the **master** branch
 
@@ -50,10 +50,6 @@ pull request for each branch.
 
 This allow us to review and pull in new features or improvements individually.
 
-## Style Guide
-
-All pull requests SHOULD adhere to the [Conventional Branch specification](https://conventionalcommits.org/)
-
 ## License
 
 You must agree that your patch will be licensed under the Conventional Commit License, and when we change the license we will assume that you agreed with the change unless you object to the changes in time.

Dockerfile

@@ -1,13 +1,13 @@
 FROM node:19.0.0-alpine
 WORKDIR /src/
-COPY ./themes/conventional-branch /src/
+COPY ./themes/devops-maturity /src/
 RUN apk add make
 RUN npm install
 RUN npm run build
 
 FROM jguyomard/hugo-builder:latest
 COPY ./ /src/
-COPY --from=0 /src/ /src/themes/conventional-branch/
+COPY --from=0 /src/ /src/themes/devops-maturity/
 RUN hugo
 
 FROM nginx:stable

Makefile

@@ -12,9 +12,9 @@ serve-site-dev:
 
 compile-assets:
 	echo "Compiling assets"
-	cd themes/conventional-branch && npm install && npm run build
+	cd themes/devops-maturity && npm install && npm run build
 	echo "Assets compiled"
 
 compile-assets-dev:
 	echo "Compiling assets"
-	cd themes/conventional-branch && npm install && npm run start &
+	cd themes/devops-maturity && npm install && npm run start &

README.md

@@ -1,22 +1,22 @@
-# The Conventional Branch Specification
+# The DevOps Maturity Specification
 
-[![Conventional Branch](https://img.shields.io/badge/Conventional%20Branch-1.0.0-blue)](https://github.com/conventional-branch/conventional-branch)
+[![DevOps Maturity](https://img.shields.io/badge/Conventional%20Branch-1.0.0-blue)](https://github.com/devops-maturity/devops-maturity)
 ![Website](https://img.shields.io/website?url=https%3A%2F%2Fconventional-branch.github.io%2F)
 
-The Conventional Branch specification defines a naming convention that brings order to your development workflow — whether you're working solo or with a team.
+The DevOps Maturity specification is standardized to assess the maturity of DevOps practices. It is a set of questions and answers to help you measure and improve your DevOps maturity.
 
 ## 🎉 Show Your Support
 
-If you find this useful, consider giving it a ⭐️ on [GitHub](https://github.com/conventional-branch/conventional-branch)! Your support helps others discover and adopt the spec.
+If you find this useful, consider giving it a ⭐️ on [GitHub](https://github.com/devops-maturity/specification)! Your support helps others discover and adopt the spec.
 
 ## 🛡 Badges!
 
-Let others know your project follows the Conventional Branch spec. Add this badge to your repository README:
+Let others know your project follows the DevOps Maturity spec. Add this badge to your repository README:
 
 ```markdown
-[![Conventional Branch](https://img.shields.io/badge/Conventional%20Branch-1.0.0-blue)](https://github.com/conventional-branch/conventional-branch)
+[![DevOps Maturity](https://img.shields.io/badge/Conventional%20Branch-1.0.0-blue)](https://github.com/devops-maturity/specification)
 ```
 
 ## 🙏 Acknowledgments
 
-Big thanks to [Conventional Commits](https://github.com/conventional-commits/conventionalcommits.org) for inspiring this project with their awesome work.
+The DevOps Maturity specification was inspired by [Conventional Branch](https://github.com/conventional-branch/conventional-branch).

config.yaml

@@ -1,6 +1,6 @@
 baseURL: '/'
 languageCode: en-us
-theme: conventional-branch
+theme: devops-maturity
 # defaultContentLanguageInSubdir: true
 defaultContentLanguage: "en"
 
@@ -15,35 +15,35 @@ params:
   footer:
     logos:
     - name: github
-      url: 'https://github.com/conventional-branch/conventional-branch'
+      url: 'https://github.com/devops-maturity/specification'
 
 # Languages parameters
 languages:
   en:
     params:
       weight: 1
       languageName: "English"
-      title: Conventional Branch
-      description: A specification for adding human and machine readable meaning to branch
+      title: DevOps Maturity
+      description: Assesment of DevOps maturity
       actions:
       - label: Quick Summary
         url: '#summary'
       - label: Full Specification
         url: '#specification'
       - label: Contribute
-        url: 'https://github.com/conventional-branch/conventional-branch'
+        url: 'https://github.com/devops-maturity/specification'
       # versions:
       #   current: v1.0.0
   zh:
     params:
       weight: 2
       languageName: "中文"
-      title: 约定式分支
-      description: 一种用于给分支增加人机可读含义的规范
+      title: DevOps 成熟度
+      description: DevOps 成熟度评估
       actions:
       - label: 概述
         url: '#概述'
       - label: 完整规范
         url: '#规范'
       - label: 贡献
-        url: 'https://github.com/conventional-branch/conventional-branch'
+        url: 'https://github.com/devops-maturity/specification'

content/_index.md

@@ -4,56 +4,58 @@ aliases: ["/en/"]
 layout: single
 ---
 
-# Conventional Branch 1.0.0
+# DevOps Maturity Specification 1.0.0
 
 ## Summary
 
-Conventional Branch refers to a structured and standardized naming convention for Git branches which aims to make branch more readable and actionable. We've suggested some branch prefixes you might want to use but you can also specify your own naming convention. A consistent naming convention makes it easier to identify branches by type.
-
-### Key Points
-
-1. **Purpose-driven Branch Names**: Each branch name clearly indicates its purpose, making it easy for all developers to understand what the branch is for.
-2. **Integration with CI/CD**: By using consistent branch names, it can help automated systems (like Continuous Integration/Continuous Deployment pipelines) to trigger specific actions based on the branch type (e.g., auto-deployment from release branches).
-3. **Team Collaboration** : It encourages collaboration within teams by making branch purpose explicit, reducing misunderstandings and making it easier for team members to switch between tasks without confusion.
-
-## Specification
-
-### Branch Naming Prefixes
-
-The branch specification by describing with `feature/`, `bugfix/`, `hotfix/`, `release/` and `chore/` and it should be structured as follows:
+DevOps Maturity Specification is a set of guidelines for DevOps best practices, focusing on improving collaboration, automation, and efficiency in software development and operations.
 
 ---
 
-```
-<type>/<description>
-```
+## Specification
 
-- **main**: The main development branch (e.g., `main`, `master`, or `develop`)
-- **feature/**: For new features (e.g., `feature/add-login-page`)
-- **bugfix/**: For bug fixes (e.g., `bugfix/fix-header-bug`)
-- **hotfix/**: For urgent fixes (e.g., `hotfix/security-patch`)
-- **release/**: For branches preparing a release (e.g., `release/v1.2.0`)
-- **chore/**: For non-code tasks like dependency, docs updates (e.g., `chore/update-dependencies`)
+### DevOps Maturity Criteria
+
+must have → 🟢
+nice to have → 🟡
+
+| **Category**        | **Criteria**                               | **Req.** | **Weight** |
+|---------------------|--------------------------------------------|----------|------------|
+| CI/CD Basic         | Build a specific branch                    | 🟢       | 1          |
+|                     | Build upon pull request                    | 🟢       | 1          |
+|                     | Build from clean environment               | 🟡       | 0.5        |
+| Quality             | Automated Testing: Functional testing      | 🟢       | 1          |
+|                     | Automated Testing: Performance testing     | 🟢       | 1          |
+|                     | Code Coverage                              | 🟡       | 0.5        |
+|                     | Accessibility Testing                      | 🟡       | 0.5        |
+| Security            | Security scan                              | 🟢       | 1          |
+|                     | License scan                               | 🟡       | 0.5        |
+| Secure Supply Chain | Documented Build Chain                     | 🟢       | 1          |
+|                     | CICD as coded                              | 🟢       | 1          |
+|                     | Artifacts are signed                       | 🟡       | 0.5        |
+|                     | Artifactory download for Package Managers  | 🟡       | 0.5        |
+| Analysis            | Quality Gate                               | 🟡       | 0.5        |
+|                     | Code Lint                                  | 🟡       | 0.5        |
+|                     | Static code analysis                       | 🟡       | 0.5        |
+|                     | Dynamic code analysis                      | 🟡       | 0.5        |
+| Reporting           | Email/Slack reporting functionality        | 🟢       | 1          |
+
+
+## Badge Levels
+
+Your score will generate one of the following badges:
+
+* WIP: 0%
+* PASSING: 1–49%
+* BRONZE: 50–69%
+* SILVER: 70–89%
+* GOLD: 90–100%
 
 ---
 
-### Basic Rules
-
-1. **Use Lowercase Alphanumeric and Hyphens**: Always use lowercase letters (a-z), numbers (0-9), and hyphens to separate words. Avoid special characters, underscores, or spaces.
-2. **No Consecutive or Trailing Hyphens**: Ensure that hyphens are used singly, with no consecutive hyphens (`feature/new--login`) or at the end (`feature/new-login-`). 
-3. **Keep It Clear and Concise**: The branch name should be descriptive yet concise, clearly indicating the purpose of the work. 
-4. **Include Ticket Numbers**: If applicable, include the ticket number from your project management tool to make tracking easier. For example, for a ticket `issue-123`, the branch name could be `feature/issue-123-new-login`.
-
-## Conclusion
-
-- **Clear Communication**: The branch name alone provides a clear understanding of its purpose the code change.
-- **Automation-Friendly**: Easily hooks into automation processes (e.g., different workflows for `feature`, `release`, etc.).
-- **Scalability**: Works well in large teams where many developers are working on different tasks simultaneously.
-
-In summary, conventional branch is designed to improve project organization, communication, and automation within Git workflows.
-
 ## FAQ
 
-### What tools can be used to automatically identify if a team member does not meet this specification?
+### What tools can be used to caculate your score?
+
+You can used [devops-maturity](https://pypi.org/project/devops-maturity) CLI to caculate your score.
 
-You can used [commit-check](https://github.com/commit-check/commit-check) to check branch specification or [commit-check-action](https://github.com/commit-check/commit-check-action) if your codes are hosted on GitHub.

content/_index.zh.md

@@ -4,56 +4,51 @@ aliases: ["/zh/"]
 layout: single
 ---
 
-# 约定式分支
+# DevOps 成熟度规范 
 
 ## 概述
 
-约定式分支是指 Git 分支的结构化和标准化命名约定，旨在使分支更具可读性和可操作性。我们建议了一些您可能想要使用的分支前缀，但您也可以指定自己的命名约定。一致的命名约定使按类型识别分支变得更加容易。
-
-### 要点
-
-1. **以目的为导向的分支名称**：每个分支名称都清楚地表明了其目的，使所有开发人员都能轻松了解该分支的用途。
-2. **与 CI/CD 集成**：通过使用一致的分支名称，它可以帮助自动化系统（如持续集成/持续部署管道）根据分支类型触发特定操作（例如，从发布分支自动部署）。
-3. **团队协作**：它通过明确分支目的来鼓励团队内部的协作，减少误解并使团队成员更容易在任务之间切换而不会产生混淆。
+DevOps 成熟度规范是一套 DevOps 最佳实践指南，旨在提升软件开发与运维的协作、自动化和效率。
 
 ## 规范
 
-### 分支命名前缀
-
-分支规范通过 `feature/`，`bugfix/`，`hotfix/`，`release/`和`chore/` 来描述，其结构应如下：
-
----
-
-```
-<type>/<description>
-```
-
-- **main**：主要开发分支（例如 `main`、`master` 或 `develop`）
-- **feature/**：用于新功能（例如 `feature/add-login-page`）
-- **bugfix/**：用于错误修复（例如 `bugfix/fix-header-bug`）
-- **hotfix/**：用于紧急修复（例如 `hotfix/security-patch`）
-- **release/**：用于准备发布的分支（例如 `release/v1.2.0`）
-- **chore/**：用于非代码任务，如依赖项、文档更新（例如 `chore/update-dependencies`）
-
----
-
-### 基本规则
-
-1. **使用小写字母、数字和连字符**：分支名称应全部使用小写字母 (a-z)、数字 (0-9) 及连字符 (-) 进行分隔。避免使用特殊字符、下划线或空格。  
-2. **禁止连续或结尾连字符**：确保连字符不连续使用 (`feature/new--login`)，且不出现在名称末尾 (`feature/new-login-`)。  
-3. **保持清晰简洁**：分支名称应简明扼要，清楚表达工作的内容和目的。  
-4. **包含工单编号**：如果适用，应包含项目管理工具中的工单编号，以便于追踪。例如，对于工单 `issue-123`，分支名称可以是 `feature/issue-123-new-login`。
-
-## 结论
-
-- **清晰的沟通**：仅凭分支名称就能清楚地了解代码更改的目的。
-- **自动化友好**：轻松挂接自动化流程（例如，针对 `feature`, `release` 等的不同工作流程）。
-- **可扩展性**：适用于许多开发人员同时处理不同任务的大型团队。
-
-总之，约定式分支旨在改善 Git 工作流程中的项目组织、沟通和自动化。
+### DevOps 成熟度评估标准
+
+必选 → 🟢  可选 → 🟡
+
+| **类别**              | **评估项**                                 | **要求** | **权重** |
+|-----------------------|--------------------------------------------|----------|----------|
+| CI/CD 基础            | 构建指定分支                               | 🟢       | 1        |
+|                       | Pull Request 自动构建                      | 🟢       | 1        |
+|                       | 干净环境构建                               | 🟡       | 0.5      |
+| 质量保障              | 自动化测试：功能测试                       | 🟢       | 1        |
+|                       | 自动化测试：性能测试                       | 🟢       | 1        |
+|                       | 代码覆盖率                                 | 🟡       | 0.5      |
+|                       | 可访问性测试                               | 🟡       | 0.5      |
+| 安全                  | 安全扫描                                   | 🟢       | 1        |
+|                       | 许可证扫描                                 | 🟡       | 0.5      |
+| 供应链安全            | 构建链文档化                               | 🟢       | 1        |
+|                       | CICD 流水线代码化                          | 🟢       | 1        |
+|                       | 制品签名                                   | 🟡       | 0.5      |
+|                       | 包管理器制品下载                           | 🟡       | 0.5      |
+| 分析                  | 质量门禁                                   | 🟡       | 0.5      |
+|                       | 代码风格检查                               | 🟡       | 0.5      |
+|                       | 静态代码分析                               | 🟡       | 0.5      |
+|                       | 动态代码分析                               | 🟡       | 0.5      |
+| 报告                  | 邮件/Slack 报告功能                        | 🟢       | 1        |
+
+## 徽章等级
+
+你的得分将获得以下徽章之一：
+
+* WIP: 0%
+* PASSING: 1–49%
+* BRONZE: 50–69%
+* SILVER: 70–89%
+* GOLD: 90–100%
 
 ## 常见问题
 
-### 如果团队成员不符合此规范，可以使用哪些工具来自动识别？
+### 如何计算得分？
 
-你可以使用 [commit-check](https://github.com/commit-check/commit-check) 来检查分支规范，或者如果你的代码托管在 GitHub 上，则使用 [commit-check-action](https://github.com/commit-check/commit-check-action)。
+您可以使用 [devops-maturity](https://pypi.org/project/devops-maturity) CLI 工具自动计算得分。