├── .eslintrc.json ├── .github ├── CODEOWNERS ├── ISSUE_TEMPLATE │ ├── bug_report.md │ ├── feature_request.md │ └── need_assistance.md ├── pull_request_template.md └── workflows │ ├── approval.yml │ ├── katacoda.yml │ ├── linters.yml │ ├── md-link-check.json │ ├── md-links.yml │ ├── upload_lambda.yml │ └── upload_lambda_from_comment.yml ├── .gitignore ├── .markdownlint.json ├── .spelling ├── CHANGELOG.md ├── CONTRIBUTING.md ├── LICENSE ├── README.md ├── assets └── online-devops-dojo │ ├── continuous-integration │ ├── ci-blue-ocean.png │ ├── dan.png │ ├── paulo.png │ ├── tina.png │ └── user-story.png │ ├── devops-kaizen │ ├── adam.png │ ├── awesome.png │ ├── brenda.png │ ├── charlie.png │ ├── chun.png │ ├── current-state.png │ ├── dan.png │ ├── improvementtheme.jpg │ ├── paulo.png │ ├── santhosh.png │ ├── selma.png │ ├── steps.png │ ├── target.png │ ├── team-chat.jpg │ ├── tina.png │ └── valuestreammap.png │ ├── leading-change │ ├── adam.png │ ├── brenda.png │ ├── charlie.png │ ├── chun.png │ ├── dan.png │ ├── first-way.png │ ├── paulo.png │ ├── santhosh.png │ ├── second-way.png │ ├── selma.png │ ├── team-chat.jpg │ ├── third-way.png │ └── tina.png │ ├── post-incident-practices │ ├── adam.png │ ├── brenda.png │ ├── charlie.png │ ├── chun.png │ ├── dan.png │ ├── paulo.png │ ├── santhosh.png │ ├── selma.png │ ├── team-chat.jpg │ └── tina.png │ ├── shift-security-left │ ├── adam.png │ ├── brenda.png │ ├── chun.png │ ├── dan.png │ ├── hal.png │ ├── jenkins-back-to-classic-icon.png │ ├── mvn-tree.png │ ├── newspaper.jpg │ ├── owasp-report.png │ ├── owasp-report2.png │ ├── paulo.png │ ├── santhosh.png │ ├── selma.png │ └── tina.png │ ├── value-stream-mapping │ ├── adam.png │ ├── brenda.png │ ├── charlie.png │ ├── chun.png │ ├── dan.png │ ├── paulo.png │ ├── santhosh.png │ ├── selma.png │ ├── team-chat.jpg │ ├── tina.png │ ├── valuestreammap-symbols.png │ └── valuestreammap.png │ ├── version-control │ ├── adam.png │ ├── dan.png │ ├── paulo.png │ ├── santhosh.png │ └── tina.png │ └── welcome │ ├── adam.png │ ├── brenda.png │ ├── charlie.png │ ├── chun.png │ ├── dan.png │ ├── hal.png │ ├── octocat.png │ ├── onceuponatime.jpg │ ├── paulo.png │ ├── petclinic.jpg │ ├── probot.jpg │ ├── santhosh.png │ ├── selma.png │ └── tina.png ├── docs ├── README.md ├── bot-setup.md ├── lambda-dojo-upload.json └── online-devops-dojo-bot.svg ├── handler.js ├── index.js ├── online-devops-dojo-pathway.json ├── online-devops-dojo ├── continuous-integration │ ├── assets │ │ ├── index.html │ │ └── prepare.sh │ ├── finish.md │ ├── index.json │ ├── intro.md │ ├── step1-verify.sh │ ├── step1.md │ ├── step2.md │ ├── step3-nospell.md │ ├── step4.md │ ├── step5.md │ ├── step6.md │ ├── step7.md │ └── step8.md ├── devops-kaizen │ ├── assets │ │ ├── add.improvement.to.backlog.sh │ │ ├── dialog.py │ │ ├── dialog1.sh │ │ ├── dialog1.yaml │ │ ├── dialog2.sh │ │ ├── dialog2.yaml │ │ ├── github-issues.py │ │ ├── github-issues.yaml │ │ └── prereq.sh │ ├── finish.md │ ├── index.json │ ├── intro.md │ ├── step1.md │ ├── step10-verify.sh │ ├── step10.md │ ├── step11.md │ ├── step12-answer.md │ ├── step12.md │ ├── step13-answer.md │ ├── step13.md │ ├── step2.md │ ├── step3-verify.sh │ ├── step3.md │ ├── step4-verify.sh │ ├── step4.md │ ├── step5-answer.md │ ├── step5.md │ ├── step6-answer.md │ ├── step6.md │ ├── step7.md │ ├── step8-answer.md │ ├── step8.md │ ├── step9-verify.sh │ └── step9.md ├── leading-change │ ├── assets │ │ ├── dialog.py │ │ ├── dialog1.sh │ │ ├── dialog1.yaml │ │ ├── dialog2.sh │ │ ├── dialog2.yaml │ │ └── prereq.sh │ ├── finish.md │ ├── index.json │ ├── intro.md │ ├── step1.md │ ├── step10-answer.md │ ├── step10.md │ ├── step11.md │ ├── step12-answer.md │ ├── step12.md │ ├── step2.md │ ├── step3.md │ ├── step4-verify.sh │ ├── step4.md │ ├── step5.md │ ├── step6-verify.sh │ ├── step6.md │ ├── step7-answer.md │ ├── step7.md │ ├── step8.md │ ├── step9-verify.sh │ └── step9.md ├── post-incident-practices │ ├── assets │ │ ├── dialog.py │ │ ├── dialog1.sh │ │ ├── dialog1.yaml │ │ ├── dialog2.sh │ │ ├── dialog2.yaml │ │ └── prereq.sh │ ├── finish.md │ ├── index.json │ ├── intro.md │ ├── step1.md │ ├── step10.md │ ├── step11-answer.md │ ├── step11.md │ ├── step2.md │ ├── step3.md │ ├── step4-verify.sh │ ├── step4.md │ ├── step5-verify.sh │ ├── step5.md │ ├── step6-answer.md │ ├── step6.md │ ├── step7-verify.sh │ ├── step7.md │ ├── step8.md │ ├── step9-answer.md │ └── step9.md ├── shift-security-left │ ├── assets │ │ ├── index.html │ │ ├── prepare.sh │ │ └── reset.sh │ ├── finish.md │ ├── index.json │ ├── intro.md │ ├── step1.md │ ├── step2-verify.sh │ ├── step2.md │ ├── step3.md │ ├── step4.md │ ├── step5-nospell.md │ ├── step6-nospell.md │ ├── step7.md │ └── step8-nospell.md ├── value-stream-mapping │ ├── assets │ │ ├── dialog.py │ │ ├── dialog1.sh │ │ ├── dialog1.yaml │ │ ├── dialog2.sh │ │ ├── dialog2.yaml │ │ └── prereq.sh │ ├── finish.md │ ├── index.json │ ├── intro.md │ ├── step1.md │ ├── step10-answer.md │ ├── step10.md │ ├── step11-verify.sh │ ├── step11.md │ ├── step12-answer.md │ ├── step12.md │ ├── step2.md │ ├── step3-verify.sh │ ├── step3.md │ ├── step4-verify.sh │ ├── step4.md │ ├── step5-answer.md │ ├── step5.md │ ├── step6-answer.md │ ├── step6.md │ ├── step7.md │ ├── step8.md │ ├── step9-answer.md │ └── step9.md ├── version-control │ ├── assets │ │ └── prepare.sh │ ├── finish.md │ ├── index.json │ ├── intro.md │ ├── step1.md │ ├── step2-verify.sh │ ├── step2.md │ ├── step3-nospell.md │ ├── step3.sh │ ├── step4.md │ ├── step5.md │ ├── step5.sh │ ├── step6.md │ ├── step6.sh │ ├── step7.md │ └── step7.sh └── welcome │ ├── assets │ ├── copy-pet-clinic.sh │ ├── github-issues.py │ ├── github-issues.yaml │ ├── github-labels.py │ └── github-labels.yaml │ ├── finish.md │ ├── index.json │ ├── intro.md │ ├── step1.md │ ├── step2.md │ ├── step3-verify.sh │ ├── step3.md │ └── step4.md ├── package-lock.json ├── package.json └── serverless.yml /.eslintrc.json: -------------------------------------------------------------------------------- 1 | { 2 | "env": { 3 | "es6": true, 4 | "node": true 5 | }, 6 | "extends": "eslint:recommended", 7 | "globals": { 8 | "Atomics": "readonly", 9 | "SharedArrayBuffer": "readonly" 10 | }, 11 | "parserOptions": { 12 | "ecmaVersion": 2018 13 | }, 14 | "rules": { 15 | "no-unused-vars": ["error", { "varsIgnorePattern": "[iI]gnored" }] 16 | } 17 | } -------------------------------------------------------------------------------- /.github/CODEOWNERS: -------------------------------------------------------------------------------- 1 | # Codeowners file 2 | # syntax: https://help.github.com/en/articles/about-code-owners 3 | * @dxc-technology/online-devops-dojo 4 | -------------------------------------------------------------------------------- /.github/ISSUE_TEMPLATE/bug_report.md: -------------------------------------------------------------------------------- 1 | --- 2 | name: Bug report 3 | about: Create a report to help us improve 4 | title: '' 5 | labels: 'bug' 6 | assignees: '' 7 | 8 | --- 9 | 10 | **Describe the bug** 11 | A clear and concise description of what the bug is. 12 | 13 | **To Reproduce** 14 | Steps to reproduce the behavior: 15 | 1. Go to '...' 16 | 2. Click on '....' 17 | 3. Scroll down to '....' 18 | 4. See error 19 | 20 | **Expected behavior** 21 | A clear and concise description of what you expected to happen. 22 | 23 | **Screenshots** 24 | If applicable, add screenshots to help explain your problem. 25 | 26 | **Additional context** 27 | Add any other context about the problem here. 28 | -------------------------------------------------------------------------------- /.github/ISSUE_TEMPLATE/feature_request.md: -------------------------------------------------------------------------------- 1 | --- 2 | name: Feature request 3 | about: Suggest an idea for this project 4 | title: '' 5 | labels: 'enhancement' 6 | assignees: '' 7 | 8 | --- 9 | 10 | **Is your feature request related to a problem? Please describe.** 11 | A clear and concise description of what the problem is. Ex. I'm always frustrated when [...] 12 | 13 | **Describe the solution you'd like** 14 | A clear and concise description of what you want to happen. 15 | 16 | **Describe alternatives you've considered** 17 | A clear and concise description of any alternative solutions or features you've considered. 18 | 19 | **Additional context** 20 | Add any other context or screenshots about the feature request here. 21 | -------------------------------------------------------------------------------- /.github/ISSUE_TEMPLATE/need_assistance.md: -------------------------------------------------------------------------------- 1 | --- 2 | name: Assistance request from student 3 | about: I have an issue with a module and I need assistance 4 | title: '' 5 | labels: ":couple: student issue" 6 | assignees: '' 7 | 8 | --- 9 | 10 | **Describe the issue** 11 | A clear and concise description of what the issue or question is. 12 | 13 | **To Reproduce** 14 | Steps to reproduce the behavior: 15 | 1. Go to '...' 16 | 2. Click on '....' 17 | 3. Scroll down to '....' 18 | 4. See error 19 | 20 | **Expected behavior** 21 | A clear and concise description of what you expected to happen. 22 | 23 | **Screenshots** 24 | If applicable, add screenshots to help explain your problem. 25 | 26 | **Additional context** 27 | Add any other context about the problem here. -------------------------------------------------------------------------------- /.github/pull_request_template.md: -------------------------------------------------------------------------------- 1 | ## Proposed changes 2 | 3 | Describe the big picture of your changes here to communicate to the maintainers why we should accept this pull request. If it fixes a bug or resolves a feature request, be sure to link to that issue. 4 | 5 | ## Types of changes 6 | 7 | What types of changes does your code introduce to Online DevOps Dojo? 8 | _Put an `x` in the boxes that apply_ 9 | 10 | - [ ] Bug fix (non-breaking change which fixes an issue) 11 | - [ ] New feature (non-breaking change which adds functionality) 12 | - [ ] Code style update (formatting, renaming) 13 | - [ ] Breaking change (fix or feature that would cause existing functionality to not work as expected) 14 | - [ ] Workflow change 15 | - [ ] Documentation update (if none of the other choices apply) 16 | 17 | ## Checklist 18 | 19 | _Put an `x` in the boxes that apply. You can also fill these out after creating the PR. If you're unsure about any of them, don't hesitate to ask. We're here to help! This is simply a reminder of what we are going to look for before merging your code._ 20 | 21 | - [ ] I have read the [CONTRIBUTING](https://github.com/dxc-technology/online-devops-dojo/blob/master/CONTRIBUTING.md) doc. 22 | - [ ] Lint passes locally with my changes. 23 | - [ ] I have added necessary documentation (if appropriate). 24 | - [ ] Any dependent changes have been merged and published in downstream modules 25 | 26 | ## Further comments 27 | 28 | If this is a relatively large or complex change, kick off the discussion by explaining why you chose the solution you did and what alternatives you considered, etc... 29 | -------------------------------------------------------------------------------- /.github/workflows/approval.yml: -------------------------------------------------------------------------------- 1 | name: Team approval workflow 2 | on: pull_request_review 3 | jobs: 4 | labelWhenApproved: 5 | runs-on: ubuntu-20.04 6 | steps: 7 | - name: Label when approved 8 | uses: pullreminders/label-when-approved-action@master 9 | env: 10 | APPROVALS: "1" 11 | GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }} 12 | ADD_LABEL: "approved" 13 | -------------------------------------------------------------------------------- /.github/workflows/katacoda.yml: -------------------------------------------------------------------------------- 1 | name: Validate Katacoda scenarios 2 | 3 | on: 4 | push: 5 | paths: 'online-devops-dojo/**' 6 | workflow_dispatch: 7 | 8 | jobs: 9 | build: 10 | name: Validate 11 | runs-on: ubuntu-20.04 12 | steps: 13 | - id: checkout-code 14 | name: Checkout code 15 | uses: actions/checkout@v2 16 | 17 | - id: validate 18 | name: Validate Katacoda scenarios 19 | run: | 20 | npx katacoda-cli validate:all --ignore=welcome --repo ${{ github.workspace }} 21 | # Ignore welcome scenario which has no title 22 | -------------------------------------------------------------------------------- /.github/workflows/linters.yml: -------------------------------------------------------------------------------- 1 | # GitHub workflow file 2 | name: Javascript linter 3 | 4 | on: 5 | push: 6 | # change(s) on those files trigger this pipeline 7 | paths: ['*.js'] 8 | 9 | jobs: 10 | linters: # run linters in separate job to not delay critical stuff 11 | timeout-minutes: 10 12 | runs-on: ubuntu-20.04 13 | 14 | steps: 15 | - name: Copy the repository 16 | uses: actions/checkout@v2 17 | 18 | # Node 12 included in LTS ubuntu-20.04 matches the version used for AWS Lambda 19 | # (https://github.com/actions/virtual-environments/blob/master/images/linux/Ubuntu2004-README.md) 20 | # hence comment the upgrade code for now 21 | # - name: Check Node 12 22 | # uses: actions/setup-node@v1.4.2 23 | # with: 24 | # node-version: 12 25 | 26 | - name: Cache node modules 27 | uses: actions/cache@v2 28 | env: 29 | cache-name: cache-node-modules 30 | with: 31 | path: ~/.npm # npm cache files are stored in `~/.npm` on Linux/macOS 32 | key: ${{ runner.os }}-build-${{ env.cache-name }}-${{ hashFiles('**/package-lock.json') }} 33 | restore-keys: | 34 | ${{ runner.os }}-build-${{ env.cache-name }}- 35 | ${{ runner.os }}-build- 36 | ${{ runner.os }}- 37 | 38 | # Install nodejs packages listed in package-lock.json. 39 | # - if: github.base_ref == 'master' 40 | - name: Install node modules 41 | run: npm ci --no-fund 42 | 43 | - name: Run linters 44 | uses: samuelmeuli/lint-action@v1 45 | with: 46 | github_token: ${{ secrets.github_token }} 47 | # Enable linters 48 | eslint: true 49 | prettier: false 50 | -------------------------------------------------------------------------------- /.github/workflows/md-link-check.json: -------------------------------------------------------------------------------- 1 | { 2 | "ignorePatterns": [ 3 | {"pattern": "HOST_SUBDOMAIN" }, 4 | {"pattern": "jdoe1000"}, 5 | {"pattern": "editor.katacoda.com"}, 6 | {"pattern": "YOUR_SHORTNAME"}, 7 | {"pattern": "your_katacoda_user"}, 8 | {"pattern": ".spelling"}, 9 | {"pattern": "/workflows/"}, 10 | {"pattern": "/actions?"} 11 | ], 12 | "aliveStatusCodes": [200,206,429] 13 | } 14 | -------------------------------------------------------------------------------- /.github/workflows/md-links.yml: -------------------------------------------------------------------------------- 1 | # GitHub workflow file 2 | name: Check links in markdown 3 | 4 | on: 5 | schedule: 6 | - cron: "1 6 */3 * *" 7 | push: 8 | paths: ['**.md', 'md-link-check.json', '.github/workflows/md-links.yml'] 9 | 10 | pull_request: 11 | paths: ['**.md', 'md-link-check.json', '.github/workflows/md-links.yml'] 12 | 13 | jobs: 14 | check-links: 15 | timeout-minutes: 10 16 | runs-on: ubuntu-20.04 17 | 18 | steps: 19 | - uses: actions/checkout@v2 20 | - uses: gaurav-nelson/github-action-markdown-link-check@v1 21 | with: 22 | config-file: '.github/workflows/md-link-check.json' 23 | use-quiet-mode: 'yes' 24 | -------------------------------------------------------------------------------- /.github/workflows/upload_lambda.yml: -------------------------------------------------------------------------------- 1 | name: Deployment of Online DevOps Dojo coach lambda 2 | 3 | on: 4 | push: 5 | # change(s) on those files trigger this pipeline 6 | paths: ['*.js', 'package*.json', 'serverless.yml', '.github/workflows/upload_lambda.yml'] 7 | branches: ['master'] 8 | 9 | jobs: 10 | build: 11 | timeout-minutes: 10 12 | runs-on: ubuntu-20.04 13 | 14 | steps: 15 | - name: Copy the repository 16 | uses: actions/checkout@v2 17 | 18 | # Node 12 included in LTS ubuntu-20.04 matches the version used for AWS Lambda 19 | # (https://github.com/actions/virtual-environments/blob/master/images/linux/Ubuntu2004-README.md) 20 | # hence comment the upgrade code for now 21 | # - name: Check Node 12 22 | # uses: actions/setup-node@v1.4.2 23 | # with: 24 | # node-version: 12 25 | 26 | # not supported yet for issue_comment event 27 | # - name: Cache node modules 28 | # uses: actions/cache@v2 29 | # env: 30 | # cache-name: cache-node-modules 31 | # with: 32 | # path: ~/.npm # npm cache files are stored in `~/.npm` on Linux/macOS 33 | # key: ${{ runner.os }}-build-${{ env.cache-name }}-${{ hashFiles('**/package-lock.json') }} 34 | # restore-keys: | 35 | # ${{ runner.os }}-build-${{ env.cache-name }}- 36 | # ${{ runner.os }}-build- 37 | # ${{ runner.os }}- 38 | 39 | # Install nodejs packages listed in package-lock.json. 40 | # - if: github.base_ref == 'master' 41 | - name: Install node modules 42 | run: npm ci --only=prod --no-fund 43 | 44 | # - if: github.base_ref == 'master' 45 | # run "serverless deploy --verbose" in a docker container and run the config file serverless.yml 46 | - name: Deploy lambda 47 | uses: serverless/github-action@v2.1.0 48 | env: # all mandatory 49 | # AWS 50 | AWS_ACCESS_KEY_ID: ${{ secrets.AWS_ACCESS_KEY }} 51 | AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_SECRET_KEY }} 52 | AWS_REGION: ${{ secrets.AWS_REGION }} 53 | AWS_STAGE: ${{ secrets.AWS_STAGE }} 54 | # GITHUB APP 55 | APP_ID: ${{ secrets.APP_ID }} 56 | WEBHOOK_SECRET: ${{ secrets.WEBHOOK_SECRET }} 57 | PRIVATE_KEY: ${{ secrets.PRIVATE_KEY }} 58 | with: 59 | args: deploy --verbose 60 | -------------------------------------------------------------------------------- /.github/workflows/upload_lambda_from_comment.yml: -------------------------------------------------------------------------------- 1 | # GitHub workflow file 2 | name: Deploy on demand Online DevOps Dojo coach lambda 3 | 4 | on: 5 | issue_comment: 6 | types: [created, edited] 7 | 8 | jobs: 9 | reaction_on_comment: 10 | runs-on: ubuntu-20.04 11 | if: startsWith(github.event.comment.body, '/deploy') 12 | 13 | steps: 14 | - name: Add reaction 15 | uses: peter-evans/create-or-update-comment@v1 16 | with: 17 | token: ${{ secrets.GITHUB_TOKEN }} 18 | comment-id: ${{ github.event.comment.id }} 19 | body: '**Go!**' 20 | reaction-type: rocket 21 | 22 | deploy_on_comment: 23 | runs-on: ubuntu-20.04 # includes Node.js 12, same version as for AWS Lambda 24 | needs: reaction_on_comment 25 | timeout-minutes: 10 26 | 27 | steps: 28 | - name: "Triggered by ${{ github.actor }}" 29 | run: echo Workflow triggered by $GITHUB_ACTOR 30 | 31 | - name: Copy the repository 32 | uses: actions/checkout@v2 33 | 34 | # Node 12 included in LTS ubuntu-20.04 matches the version used for AWS Lambda 35 | # (https://github.com/actions/virtual-environments/blob/master/images/linux/Ubuntu2004-README.md) 36 | # hence comment the upgrade code for now 37 | # - name: Check Node 12 38 | # uses: actions/setup-node@v1.4.2 39 | # with: 40 | # node-version: 12 41 | 42 | # not supported yet for issue_comment event 43 | # - name: Cache node modules 44 | # uses: actions/cache@v2 45 | # env: 46 | # cache-name: cache-node-modules 47 | # with: 48 | # path: ~/.npm # npm cache files are stored in `~/.npm` on Linux/macOS 49 | # key: ${{ runner.os }}-build-${{ env.cache-name }}-${{ hashFiles('**/package-lock.json') }} 50 | # restore-keys: | 51 | # ${{ runner.os }}-build-${{ env.cache-name }}- 52 | # ${{ runner.os }}-build- 53 | # ${{ runner.os }}- 54 | 55 | # Install nodejs packages listed in package-lock.json. 56 | - name: Install node modules 57 | run: npm ci --only=prod --no-fund 58 | 59 | # run "serverless deploy --verbose" in a docker container and run the config file serverless.yml 60 | - name: Deploy lambda 61 | uses: serverless/github-action@v2.1.0 62 | env: # all mandatory 63 | # AWS 64 | AWS_ACCESS_KEY_ID: ${{ secrets.AWS_ACCESS_KEY }} 65 | AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_SECRET_KEY }} 66 | AWS_REGION: ${{ secrets.AWS_REGION }} 67 | AWS_STAGE: ${{ secrets.AWS_STAGE }} 68 | # GITHUB APP 69 | APP_ID: ${{ secrets.APP_ID }} 70 | WEBHOOK_SECRET: ${{ secrets.WEBHOOK_SECRET }} 71 | PRIVATE_KEY: ${{ secrets.PRIVATE_KEY }} 72 | with: 73 | args: deploy --verbose 74 | -------------------------------------------------------------------------------- /.gitignore: -------------------------------------------------------------------------------- 1 | # Byte-compiled / optimized / DLL files 2 | __pycache__/ 3 | *.py[cod] 4 | *$py.class 5 | 6 | # C extensions 7 | *.so 8 | 9 | # Distribution / packaging 10 | .Python 11 | build/ 12 | develop-eggs/ 13 | dist/ 14 | downloads/ 15 | eggs/ 16 | .eggs/ 17 | lib/ 18 | lib64/ 19 | parts/ 20 | sdist/ 21 | var/ 22 | wheels/ 23 | *.egg-info/ 24 | .installed.cfg 25 | *.egg 26 | MANIFEST 27 | 28 | # PyInstaller 29 | # Usually these files are written by a python script from a template 30 | # before PyInstaller builds the exe, so as to inject date/other infos into it. 31 | *.manifest 32 | *.spec 33 | 34 | # Installer logs 35 | pip-log.txt 36 | pip-delete-this-directory.txt 37 | 38 | # Unit test / coverage reports 39 | htmlcov/ 40 | .tox/ 41 | .coverage 42 | .coverage.* 43 | .cache 44 | nosetests.xml 45 | coverage.xml 46 | *.cover 47 | .hypothesis/ 48 | .pytest_cache/ 49 | 50 | # Translations 51 | *.mo 52 | *.pot 53 | 54 | # Django stuff: 55 | *.log 56 | local_settings.py 57 | db.sqlite3 58 | 59 | # Flask stuff: 60 | instance/ 61 | .webassets-cache 62 | 63 | # Scrapy stuff: 64 | .scrapy 65 | 66 | # Sphinx documentation 67 | docs/_build/ 68 | 69 | # PyBuilder 70 | target/ 71 | 72 | # Jupyter Notebook 73 | .ipynb_checkpoints 74 | 75 | # pyenv 76 | .python-version 77 | 78 | # celery beat schedule file 79 | celerybeat-schedule 80 | 81 | # SageMath parsed files 82 | *.sage.py 83 | 84 | # Environments 85 | .env 86 | .venv 87 | env/ 88 | venv/ 89 | ENV/ 90 | env.bak/ 91 | venv.bak/ 92 | 93 | # Spyder project settings 94 | .spyderproject 95 | .spyproject 96 | 97 | # Rope project settings 98 | .ropeproject 99 | 100 | # mkdocs documentation 101 | /site 102 | 103 | # mypy 104 | .mypy_cache/ 105 | 106 | # node packages 107 | node_modules 108 | -------------------------------------------------------------------------------- /.markdownlint.json: -------------------------------------------------------------------------------- 1 | { 2 | "default": true, 3 | "line-length": false, 4 | "no-inline-html": { 5 | "allowed_elements": [ "svg", "path", "ins", "kbd", "pre", "a", "details", "summary", "div", "br" ] 6 | }, 7 | "first-line-h1": false, 8 | "no-duplicate-header": false 9 | } -------------------------------------------------------------------------------- /.spelling: -------------------------------------------------------------------------------- 1 | # Custom spelling dictionary for use with Node.js Markdown Spellcheck (mdspell) 2 | 3 | DevOps 4 | dojo 5 | # "de facto" not well recognized 6 | facto 7 | Kaizen 8 | LessOps 9 | NoOps 10 | Octocat 11 | repo 12 | serverless 13 | webhook 14 | 15 | e.g. 16 | i.e. 17 | # as in Mos Eisley 18 | Eisley 19 | 20 | # Proper Names from the course 21 | Chun 22 | Paulo 23 | Santhosh 24 | 25 | # Product & Vendor Names 26 | # Place them here with their proper case to help enforce consistently aligned with that product or vendor's preference. 27 | Fortnite 28 | Royale 29 | GitHub 30 | JFrog 31 | Katacoda 32 | Kubernetes 33 | Node.js 34 | -------------------------------------------------------------------------------- /CHANGELOG.md: -------------------------------------------------------------------------------- 1 | # Changelog 2 | 3 | All notable changes to this project will be documented in this file. 4 | 5 | The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/), 6 | and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html). 7 | 8 | ## [1.6.1] - 2021-08-20 9 | 10 | ### Fixed 11 | 12 | - Error running prepare.sh in version control module 13 | 14 | ## [1.6.0] - 2020-12-15 15 | 16 | ### Added 17 | 18 | - Post Incident Practices Module 19 | 20 | ## [1.5.1] - 2020-12-13 21 | 22 | ### Changed 23 | 24 | - Introduced Dojo Octocat in Welcome module 25 | 26 | ## [1.5.0] - 2020-10-21 27 | 28 | ### Changed 29 | 30 | - Bump serverless to v2.1. 31 | - Run the link checker every 3 days only. 32 | 33 | ## [1.4.1] - 2020-10-11 34 | 35 | ### Fixed 36 | 37 | - Updated estimated times for VSM and Kaizen modules 38 | 39 | ## [1.4.0] - 2020-10-09 40 | 41 | ### Changed 42 | 43 | - Add Javascript linter. 44 | - Upgrade GitHub Actions virtual environment to Ubuntu LTS 20.04. 45 | - Bump markdown link checker. 46 | - Markdown link checker ignore HTTP 429 Too Many Requests. 47 | - Trigger the markdown link checker on commit on markdown files and linter only. 48 | - Bump NPM dependencies. 49 | - Add workflow badges. 50 | 51 | ## [1.3.0] - 2020-10-05 52 | 53 | ### Added 54 | 55 | - Value Stream Mapping and DevOps Kaizen modules. 56 | - Upgrade GitHub Actions virtual environment to Ubuntu LTS 20.04. 57 | 58 | ## [1.2.1] - 2020-06-26 59 | 60 | ### Fixed 61 | 62 | - Bump Node.js dependencies. 63 | - GitHub app prefilled URL form using local team-chat.jpg. 64 | 65 | ## [1.2.0] - 2020-05-06 66 | 67 | ### Changed 68 | 69 | - Improve coach logging. 70 | - Use repository images for bot comments and notifications. 71 | 72 | ### Fixed 73 | 74 | - Dojo coach wasn't able to merge PR. 75 | 76 | ## [1.1.0] - 2020-04-08 77 | 78 | ### Added 79 | 80 | - Trigger the lambda upload from a comment. 81 | - Approval workflow. 82 | 83 | ### Changed 84 | 85 | - Use / instead of @ to invoke the coach. 86 | - Add Node.js caching step in lambda upload workflow. 87 | - Add APP_ID secret and rename AWS secrets. 88 | 89 | ### Fixed 90 | 91 | - Cleanup of previous webhooks. 92 | - Update OWASP links. 93 | 94 | ## [1.0.2] - 2020-03-27 95 | 96 | - Version control: update a few line numbers, fine tune instructions. 97 | - Add stale action. 98 | 99 | ## [1.0.1] - 2020-03-20 100 | 101 | ### Changed 102 | 103 | - Update Shift Left on Security module with updated dependencies of Pet Clinic. 104 | - Bump NPM dependencies 105 | - Replace Katacoda internal tab for Jenkins with a browser tab (workaround for Chrome sameSite cookie issue). 106 | 107 | ## [1.0.0] - 2019-07-16 108 | 109 | ### Added 110 | 111 | - Initial version 112 | -------------------------------------------------------------------------------- /assets/online-devops-dojo/continuous-integration/ci-blue-ocean.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/dxc-technology/online-devops-dojo/0038f54b46b9a39e1ed9b4d7022d5150c1ba01fa/assets/online-devops-dojo/continuous-integration/ci-blue-ocean.png -------------------------------------------------------------------------------- /assets/online-devops-dojo/continuous-integration/dan.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/dxc-technology/online-devops-dojo/0038f54b46b9a39e1ed9b4d7022d5150c1ba01fa/assets/online-devops-dojo/continuous-integration/dan.png -------------------------------------------------------------------------------- /assets/online-devops-dojo/continuous-integration/paulo.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/dxc-technology/online-devops-dojo/0038f54b46b9a39e1ed9b4d7022d5150c1ba01fa/assets/online-devops-dojo/continuous-integration/paulo.png -------------------------------------------------------------------------------- /assets/online-devops-dojo/continuous-integration/tina.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/dxc-technology/online-devops-dojo/0038f54b46b9a39e1ed9b4d7022d5150c1ba01fa/assets/online-devops-dojo/continuous-integration/tina.png -------------------------------------------------------------------------------- /assets/online-devops-dojo/continuous-integration/user-story.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/dxc-technology/online-devops-dojo/0038f54b46b9a39e1ed9b4d7022d5150c1ba01fa/assets/online-devops-dojo/continuous-integration/user-story.png -------------------------------------------------------------------------------- /assets/online-devops-dojo/devops-kaizen/adam.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/dxc-technology/online-devops-dojo/0038f54b46b9a39e1ed9b4d7022d5150c1ba01fa/assets/online-devops-dojo/devops-kaizen/adam.png -------------------------------------------------------------------------------- /assets/online-devops-dojo/devops-kaizen/awesome.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/dxc-technology/online-devops-dojo/0038f54b46b9a39e1ed9b4d7022d5150c1ba01fa/assets/online-devops-dojo/devops-kaizen/awesome.png -------------------------------------------------------------------------------- /assets/online-devops-dojo/devops-kaizen/brenda.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/dxc-technology/online-devops-dojo/0038f54b46b9a39e1ed9b4d7022d5150c1ba01fa/assets/online-devops-dojo/devops-kaizen/brenda.png -------------------------------------------------------------------------------- /assets/online-devops-dojo/devops-kaizen/charlie.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/dxc-technology/online-devops-dojo/0038f54b46b9a39e1ed9b4d7022d5150c1ba01fa/assets/online-devops-dojo/devops-kaizen/charlie.png -------------------------------------------------------------------------------- /assets/online-devops-dojo/devops-kaizen/chun.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/dxc-technology/online-devops-dojo/0038f54b46b9a39e1ed9b4d7022d5150c1ba01fa/assets/online-devops-dojo/devops-kaizen/chun.png -------------------------------------------------------------------------------- /assets/online-devops-dojo/devops-kaizen/current-state.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/dxc-technology/online-devops-dojo/0038f54b46b9a39e1ed9b4d7022d5150c1ba01fa/assets/online-devops-dojo/devops-kaizen/current-state.png -------------------------------------------------------------------------------- /assets/online-devops-dojo/devops-kaizen/dan.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/dxc-technology/online-devops-dojo/0038f54b46b9a39e1ed9b4d7022d5150c1ba01fa/assets/online-devops-dojo/devops-kaizen/dan.png -------------------------------------------------------------------------------- /assets/online-devops-dojo/devops-kaizen/improvementtheme.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/dxc-technology/online-devops-dojo/0038f54b46b9a39e1ed9b4d7022d5150c1ba01fa/assets/online-devops-dojo/devops-kaizen/improvementtheme.jpg -------------------------------------------------------------------------------- /assets/online-devops-dojo/devops-kaizen/paulo.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/dxc-technology/online-devops-dojo/0038f54b46b9a39e1ed9b4d7022d5150c1ba01fa/assets/online-devops-dojo/devops-kaizen/paulo.png -------------------------------------------------------------------------------- /assets/online-devops-dojo/devops-kaizen/santhosh.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/dxc-technology/online-devops-dojo/0038f54b46b9a39e1ed9b4d7022d5150c1ba01fa/assets/online-devops-dojo/devops-kaizen/santhosh.png -------------------------------------------------------------------------------- /assets/online-devops-dojo/devops-kaizen/selma.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/dxc-technology/online-devops-dojo/0038f54b46b9a39e1ed9b4d7022d5150c1ba01fa/assets/online-devops-dojo/devops-kaizen/selma.png -------------------------------------------------------------------------------- /assets/online-devops-dojo/devops-kaizen/steps.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/dxc-technology/online-devops-dojo/0038f54b46b9a39e1ed9b4d7022d5150c1ba01fa/assets/online-devops-dojo/devops-kaizen/steps.png -------------------------------------------------------------------------------- /assets/online-devops-dojo/devops-kaizen/target.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/dxc-technology/online-devops-dojo/0038f54b46b9a39e1ed9b4d7022d5150c1ba01fa/assets/online-devops-dojo/devops-kaizen/target.png -------------------------------------------------------------------------------- /assets/online-devops-dojo/devops-kaizen/team-chat.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/dxc-technology/online-devops-dojo/0038f54b46b9a39e1ed9b4d7022d5150c1ba01fa/assets/online-devops-dojo/devops-kaizen/team-chat.jpg -------------------------------------------------------------------------------- /assets/online-devops-dojo/devops-kaizen/tina.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/dxc-technology/online-devops-dojo/0038f54b46b9a39e1ed9b4d7022d5150c1ba01fa/assets/online-devops-dojo/devops-kaizen/tina.png -------------------------------------------------------------------------------- /assets/online-devops-dojo/devops-kaizen/valuestreammap.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/dxc-technology/online-devops-dojo/0038f54b46b9a39e1ed9b4d7022d5150c1ba01fa/assets/online-devops-dojo/devops-kaizen/valuestreammap.png -------------------------------------------------------------------------------- /assets/online-devops-dojo/leading-change/adam.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/dxc-technology/online-devops-dojo/0038f54b46b9a39e1ed9b4d7022d5150c1ba01fa/assets/online-devops-dojo/leading-change/adam.png -------------------------------------------------------------------------------- /assets/online-devops-dojo/leading-change/brenda.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/dxc-technology/online-devops-dojo/0038f54b46b9a39e1ed9b4d7022d5150c1ba01fa/assets/online-devops-dojo/leading-change/brenda.png -------------------------------------------------------------------------------- /assets/online-devops-dojo/leading-change/charlie.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/dxc-technology/online-devops-dojo/0038f54b46b9a39e1ed9b4d7022d5150c1ba01fa/assets/online-devops-dojo/leading-change/charlie.png -------------------------------------------------------------------------------- /assets/online-devops-dojo/leading-change/chun.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/dxc-technology/online-devops-dojo/0038f54b46b9a39e1ed9b4d7022d5150c1ba01fa/assets/online-devops-dojo/leading-change/chun.png -------------------------------------------------------------------------------- /assets/online-devops-dojo/leading-change/dan.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/dxc-technology/online-devops-dojo/0038f54b46b9a39e1ed9b4d7022d5150c1ba01fa/assets/online-devops-dojo/leading-change/dan.png -------------------------------------------------------------------------------- /assets/online-devops-dojo/leading-change/first-way.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/dxc-technology/online-devops-dojo/0038f54b46b9a39e1ed9b4d7022d5150c1ba01fa/assets/online-devops-dojo/leading-change/first-way.png -------------------------------------------------------------------------------- /assets/online-devops-dojo/leading-change/paulo.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/dxc-technology/online-devops-dojo/0038f54b46b9a39e1ed9b4d7022d5150c1ba01fa/assets/online-devops-dojo/leading-change/paulo.png -------------------------------------------------------------------------------- /assets/online-devops-dojo/leading-change/santhosh.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/dxc-technology/online-devops-dojo/0038f54b46b9a39e1ed9b4d7022d5150c1ba01fa/assets/online-devops-dojo/leading-change/santhosh.png -------------------------------------------------------------------------------- /assets/online-devops-dojo/leading-change/second-way.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/dxc-technology/online-devops-dojo/0038f54b46b9a39e1ed9b4d7022d5150c1ba01fa/assets/online-devops-dojo/leading-change/second-way.png -------------------------------------------------------------------------------- /assets/online-devops-dojo/leading-change/selma.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/dxc-technology/online-devops-dojo/0038f54b46b9a39e1ed9b4d7022d5150c1ba01fa/assets/online-devops-dojo/leading-change/selma.png -------------------------------------------------------------------------------- /assets/online-devops-dojo/leading-change/team-chat.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/dxc-technology/online-devops-dojo/0038f54b46b9a39e1ed9b4d7022d5150c1ba01fa/assets/online-devops-dojo/leading-change/team-chat.jpg -------------------------------------------------------------------------------- /assets/online-devops-dojo/leading-change/third-way.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/dxc-technology/online-devops-dojo/0038f54b46b9a39e1ed9b4d7022d5150c1ba01fa/assets/online-devops-dojo/leading-change/third-way.png -------------------------------------------------------------------------------- /assets/online-devops-dojo/leading-change/tina.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/dxc-technology/online-devops-dojo/0038f54b46b9a39e1ed9b4d7022d5150c1ba01fa/assets/online-devops-dojo/leading-change/tina.png -------------------------------------------------------------------------------- /assets/online-devops-dojo/post-incident-practices/adam.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/dxc-technology/online-devops-dojo/0038f54b46b9a39e1ed9b4d7022d5150c1ba01fa/assets/online-devops-dojo/post-incident-practices/adam.png -------------------------------------------------------------------------------- /assets/online-devops-dojo/post-incident-practices/brenda.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/dxc-technology/online-devops-dojo/0038f54b46b9a39e1ed9b4d7022d5150c1ba01fa/assets/online-devops-dojo/post-incident-practices/brenda.png -------------------------------------------------------------------------------- /assets/online-devops-dojo/post-incident-practices/charlie.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/dxc-technology/online-devops-dojo/0038f54b46b9a39e1ed9b4d7022d5150c1ba01fa/assets/online-devops-dojo/post-incident-practices/charlie.png -------------------------------------------------------------------------------- /assets/online-devops-dojo/post-incident-practices/chun.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/dxc-technology/online-devops-dojo/0038f54b46b9a39e1ed9b4d7022d5150c1ba01fa/assets/online-devops-dojo/post-incident-practices/chun.png -------------------------------------------------------------------------------- /assets/online-devops-dojo/post-incident-practices/dan.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/dxc-technology/online-devops-dojo/0038f54b46b9a39e1ed9b4d7022d5150c1ba01fa/assets/online-devops-dojo/post-incident-practices/dan.png -------------------------------------------------------------------------------- /assets/online-devops-dojo/post-incident-practices/paulo.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/dxc-technology/online-devops-dojo/0038f54b46b9a39e1ed9b4d7022d5150c1ba01fa/assets/online-devops-dojo/post-incident-practices/paulo.png -------------------------------------------------------------------------------- /assets/online-devops-dojo/post-incident-practices/santhosh.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/dxc-technology/online-devops-dojo/0038f54b46b9a39e1ed9b4d7022d5150c1ba01fa/assets/online-devops-dojo/post-incident-practices/santhosh.png -------------------------------------------------------------------------------- /assets/online-devops-dojo/post-incident-practices/selma.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/dxc-technology/online-devops-dojo/0038f54b46b9a39e1ed9b4d7022d5150c1ba01fa/assets/online-devops-dojo/post-incident-practices/selma.png -------------------------------------------------------------------------------- /assets/online-devops-dojo/post-incident-practices/team-chat.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/dxc-technology/online-devops-dojo/0038f54b46b9a39e1ed9b4d7022d5150c1ba01fa/assets/online-devops-dojo/post-incident-practices/team-chat.jpg -------------------------------------------------------------------------------- /assets/online-devops-dojo/post-incident-practices/tina.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/dxc-technology/online-devops-dojo/0038f54b46b9a39e1ed9b4d7022d5150c1ba01fa/assets/online-devops-dojo/post-incident-practices/tina.png -------------------------------------------------------------------------------- /assets/online-devops-dojo/shift-security-left/adam.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/dxc-technology/online-devops-dojo/0038f54b46b9a39e1ed9b4d7022d5150c1ba01fa/assets/online-devops-dojo/shift-security-left/adam.png -------------------------------------------------------------------------------- /assets/online-devops-dojo/shift-security-left/brenda.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/dxc-technology/online-devops-dojo/0038f54b46b9a39e1ed9b4d7022d5150c1ba01fa/assets/online-devops-dojo/shift-security-left/brenda.png -------------------------------------------------------------------------------- /assets/online-devops-dojo/shift-security-left/chun.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/dxc-technology/online-devops-dojo/0038f54b46b9a39e1ed9b4d7022d5150c1ba01fa/assets/online-devops-dojo/shift-security-left/chun.png -------------------------------------------------------------------------------- /assets/online-devops-dojo/shift-security-left/dan.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/dxc-technology/online-devops-dojo/0038f54b46b9a39e1ed9b4d7022d5150c1ba01fa/assets/online-devops-dojo/shift-security-left/dan.png -------------------------------------------------------------------------------- /assets/online-devops-dojo/shift-security-left/hal.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/dxc-technology/online-devops-dojo/0038f54b46b9a39e1ed9b4d7022d5150c1ba01fa/assets/online-devops-dojo/shift-security-left/hal.png -------------------------------------------------------------------------------- /assets/online-devops-dojo/shift-security-left/jenkins-back-to-classic-icon.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/dxc-technology/online-devops-dojo/0038f54b46b9a39e1ed9b4d7022d5150c1ba01fa/assets/online-devops-dojo/shift-security-left/jenkins-back-to-classic-icon.png -------------------------------------------------------------------------------- /assets/online-devops-dojo/shift-security-left/mvn-tree.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/dxc-technology/online-devops-dojo/0038f54b46b9a39e1ed9b4d7022d5150c1ba01fa/assets/online-devops-dojo/shift-security-left/mvn-tree.png -------------------------------------------------------------------------------- /assets/online-devops-dojo/shift-security-left/newspaper.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/dxc-technology/online-devops-dojo/0038f54b46b9a39e1ed9b4d7022d5150c1ba01fa/assets/online-devops-dojo/shift-security-left/newspaper.jpg -------------------------------------------------------------------------------- /assets/online-devops-dojo/shift-security-left/owasp-report.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/dxc-technology/online-devops-dojo/0038f54b46b9a39e1ed9b4d7022d5150c1ba01fa/assets/online-devops-dojo/shift-security-left/owasp-report.png -------------------------------------------------------------------------------- /assets/online-devops-dojo/shift-security-left/owasp-report2.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/dxc-technology/online-devops-dojo/0038f54b46b9a39e1ed9b4d7022d5150c1ba01fa/assets/online-devops-dojo/shift-security-left/owasp-report2.png -------------------------------------------------------------------------------- /assets/online-devops-dojo/shift-security-left/paulo.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/dxc-technology/online-devops-dojo/0038f54b46b9a39e1ed9b4d7022d5150c1ba01fa/assets/online-devops-dojo/shift-security-left/paulo.png -------------------------------------------------------------------------------- /assets/online-devops-dojo/shift-security-left/santhosh.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/dxc-technology/online-devops-dojo/0038f54b46b9a39e1ed9b4d7022d5150c1ba01fa/assets/online-devops-dojo/shift-security-left/santhosh.png -------------------------------------------------------------------------------- /assets/online-devops-dojo/shift-security-left/selma.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/dxc-technology/online-devops-dojo/0038f54b46b9a39e1ed9b4d7022d5150c1ba01fa/assets/online-devops-dojo/shift-security-left/selma.png -------------------------------------------------------------------------------- /assets/online-devops-dojo/shift-security-left/tina.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/dxc-technology/online-devops-dojo/0038f54b46b9a39e1ed9b4d7022d5150c1ba01fa/assets/online-devops-dojo/shift-security-left/tina.png -------------------------------------------------------------------------------- /assets/online-devops-dojo/value-stream-mapping/adam.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/dxc-technology/online-devops-dojo/0038f54b46b9a39e1ed9b4d7022d5150c1ba01fa/assets/online-devops-dojo/value-stream-mapping/adam.png -------------------------------------------------------------------------------- /assets/online-devops-dojo/value-stream-mapping/brenda.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/dxc-technology/online-devops-dojo/0038f54b46b9a39e1ed9b4d7022d5150c1ba01fa/assets/online-devops-dojo/value-stream-mapping/brenda.png -------------------------------------------------------------------------------- /assets/online-devops-dojo/value-stream-mapping/charlie.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/dxc-technology/online-devops-dojo/0038f54b46b9a39e1ed9b4d7022d5150c1ba01fa/assets/online-devops-dojo/value-stream-mapping/charlie.png -------------------------------------------------------------------------------- /assets/online-devops-dojo/value-stream-mapping/chun.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/dxc-technology/online-devops-dojo/0038f54b46b9a39e1ed9b4d7022d5150c1ba01fa/assets/online-devops-dojo/value-stream-mapping/chun.png -------------------------------------------------------------------------------- /assets/online-devops-dojo/value-stream-mapping/dan.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/dxc-technology/online-devops-dojo/0038f54b46b9a39e1ed9b4d7022d5150c1ba01fa/assets/online-devops-dojo/value-stream-mapping/dan.png -------------------------------------------------------------------------------- /assets/online-devops-dojo/value-stream-mapping/paulo.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/dxc-technology/online-devops-dojo/0038f54b46b9a39e1ed9b4d7022d5150c1ba01fa/assets/online-devops-dojo/value-stream-mapping/paulo.png -------------------------------------------------------------------------------- /assets/online-devops-dojo/value-stream-mapping/santhosh.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/dxc-technology/online-devops-dojo/0038f54b46b9a39e1ed9b4d7022d5150c1ba01fa/assets/online-devops-dojo/value-stream-mapping/santhosh.png -------------------------------------------------------------------------------- /assets/online-devops-dojo/value-stream-mapping/selma.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/dxc-technology/online-devops-dojo/0038f54b46b9a39e1ed9b4d7022d5150c1ba01fa/assets/online-devops-dojo/value-stream-mapping/selma.png -------------------------------------------------------------------------------- /assets/online-devops-dojo/value-stream-mapping/team-chat.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/dxc-technology/online-devops-dojo/0038f54b46b9a39e1ed9b4d7022d5150c1ba01fa/assets/online-devops-dojo/value-stream-mapping/team-chat.jpg -------------------------------------------------------------------------------- /assets/online-devops-dojo/value-stream-mapping/tina.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/dxc-technology/online-devops-dojo/0038f54b46b9a39e1ed9b4d7022d5150c1ba01fa/assets/online-devops-dojo/value-stream-mapping/tina.png -------------------------------------------------------------------------------- /assets/online-devops-dojo/value-stream-mapping/valuestreammap-symbols.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/dxc-technology/online-devops-dojo/0038f54b46b9a39e1ed9b4d7022d5150c1ba01fa/assets/online-devops-dojo/value-stream-mapping/valuestreammap-symbols.png -------------------------------------------------------------------------------- /assets/online-devops-dojo/value-stream-mapping/valuestreammap.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/dxc-technology/online-devops-dojo/0038f54b46b9a39e1ed9b4d7022d5150c1ba01fa/assets/online-devops-dojo/value-stream-mapping/valuestreammap.png -------------------------------------------------------------------------------- /assets/online-devops-dojo/version-control/adam.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/dxc-technology/online-devops-dojo/0038f54b46b9a39e1ed9b4d7022d5150c1ba01fa/assets/online-devops-dojo/version-control/adam.png -------------------------------------------------------------------------------- /assets/online-devops-dojo/version-control/dan.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/dxc-technology/online-devops-dojo/0038f54b46b9a39e1ed9b4d7022d5150c1ba01fa/assets/online-devops-dojo/version-control/dan.png -------------------------------------------------------------------------------- /assets/online-devops-dojo/version-control/paulo.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/dxc-technology/online-devops-dojo/0038f54b46b9a39e1ed9b4d7022d5150c1ba01fa/assets/online-devops-dojo/version-control/paulo.png -------------------------------------------------------------------------------- /assets/online-devops-dojo/version-control/santhosh.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/dxc-technology/online-devops-dojo/0038f54b46b9a39e1ed9b4d7022d5150c1ba01fa/assets/online-devops-dojo/version-control/santhosh.png -------------------------------------------------------------------------------- /assets/online-devops-dojo/version-control/tina.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/dxc-technology/online-devops-dojo/0038f54b46b9a39e1ed9b4d7022d5150c1ba01fa/assets/online-devops-dojo/version-control/tina.png -------------------------------------------------------------------------------- /assets/online-devops-dojo/welcome/adam.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/dxc-technology/online-devops-dojo/0038f54b46b9a39e1ed9b4d7022d5150c1ba01fa/assets/online-devops-dojo/welcome/adam.png -------------------------------------------------------------------------------- /assets/online-devops-dojo/welcome/brenda.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/dxc-technology/online-devops-dojo/0038f54b46b9a39e1ed9b4d7022d5150c1ba01fa/assets/online-devops-dojo/welcome/brenda.png -------------------------------------------------------------------------------- /assets/online-devops-dojo/welcome/charlie.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/dxc-technology/online-devops-dojo/0038f54b46b9a39e1ed9b4d7022d5150c1ba01fa/assets/online-devops-dojo/welcome/charlie.png -------------------------------------------------------------------------------- /assets/online-devops-dojo/welcome/chun.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/dxc-technology/online-devops-dojo/0038f54b46b9a39e1ed9b4d7022d5150c1ba01fa/assets/online-devops-dojo/welcome/chun.png -------------------------------------------------------------------------------- /assets/online-devops-dojo/welcome/dan.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/dxc-technology/online-devops-dojo/0038f54b46b9a39e1ed9b4d7022d5150c1ba01fa/assets/online-devops-dojo/welcome/dan.png -------------------------------------------------------------------------------- /assets/online-devops-dojo/welcome/hal.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/dxc-technology/online-devops-dojo/0038f54b46b9a39e1ed9b4d7022d5150c1ba01fa/assets/online-devops-dojo/welcome/hal.png -------------------------------------------------------------------------------- /assets/online-devops-dojo/welcome/octocat.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/dxc-technology/online-devops-dojo/0038f54b46b9a39e1ed9b4d7022d5150c1ba01fa/assets/online-devops-dojo/welcome/octocat.png -------------------------------------------------------------------------------- /assets/online-devops-dojo/welcome/onceuponatime.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/dxc-technology/online-devops-dojo/0038f54b46b9a39e1ed9b4d7022d5150c1ba01fa/assets/online-devops-dojo/welcome/onceuponatime.jpg -------------------------------------------------------------------------------- /assets/online-devops-dojo/welcome/paulo.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/dxc-technology/online-devops-dojo/0038f54b46b9a39e1ed9b4d7022d5150c1ba01fa/assets/online-devops-dojo/welcome/paulo.png -------------------------------------------------------------------------------- /assets/online-devops-dojo/welcome/petclinic.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/dxc-technology/online-devops-dojo/0038f54b46b9a39e1ed9b4d7022d5150c1ba01fa/assets/online-devops-dojo/welcome/petclinic.jpg -------------------------------------------------------------------------------- /assets/online-devops-dojo/welcome/probot.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/dxc-technology/online-devops-dojo/0038f54b46b9a39e1ed9b4d7022d5150c1ba01fa/assets/online-devops-dojo/welcome/probot.jpg -------------------------------------------------------------------------------- /assets/online-devops-dojo/welcome/santhosh.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/dxc-technology/online-devops-dojo/0038f54b46b9a39e1ed9b4d7022d5150c1ba01fa/assets/online-devops-dojo/welcome/santhosh.png -------------------------------------------------------------------------------- /assets/online-devops-dojo/welcome/selma.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/dxc-technology/online-devops-dojo/0038f54b46b9a39e1ed9b4d7022d5150c1ba01fa/assets/online-devops-dojo/welcome/selma.png -------------------------------------------------------------------------------- /assets/online-devops-dojo/welcome/tina.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/dxc-technology/online-devops-dojo/0038f54b46b9a39e1ed9b4d7022d5150c1ba01fa/assets/online-devops-dojo/welcome/tina.png -------------------------------------------------------------------------------- /docs/README.md: -------------------------------------------------------------------------------- 1 | # Online DevOps Dojo coach ![](../../../workflows/Deployment%20of%20Online%20DevOps%20Dojo%20coach%20lambda/badge.svg) 2 | 3 | The Online DevOps Dojo coach is here to make the DevOps learning experience 4 | even more enjoyable. 5 | 6 | Actually the coach is a robot which allows you to interact with the "Charlie 7 | Veterinary Clinic" virtual team in the context of GitHub issues and pull 8 | requests. 9 | 10 | One can imagine a lot of funny exchanges which at some point will require a 11 | genuine test pipeline! 12 | 13 | ![Team chat](https://raw.githubusercontent.com/dxc-technology/online-devops-dojo/master/assets/online-devops-dojo/leading-change/team-chat.jpg) 14 | 15 | ## Setup 16 | 17 | How to [Setup](./bot-setup.md) your custom instance of the robot. 18 | 19 | ## High level architecture 20 | 21 | Our implementation uses a GitHub application with [Probot](https://probot.github.io/) 22 | and upload an AWS Lambda function using [GitHub Actions](https://github.com/features/actions) 23 | and [Serverless](https://serverless.com/). 24 | 25 | ![Architecture diagram](online-devops-dojo-bot.svg) 26 | 27 | Other architectures are of course possible without changing anything to the 28 | Probot application. 29 | For example, we have another instance running in a container 30 | in Kubernetes. The GitHub workflow is replaced by a Jenkins pipeline and 31 | Serverless by a Helm chart. 32 | 33 | ## Developing 34 | 35 | DevOps Dojo Coach is a 36 | [GitHub App](https://developer.github.com/apps/about-apps/) built with 37 | [Probot](https://probot.github.io/) framework on Node.js. Its embedded 38 | [logging](https://probot.github.io/docs/logging/) API is 39 | [bunyan](https://github.com/trentm/node-bunyan). 40 | 41 | The custom bot code is fully contained in the file index.js. 42 | 43 | The bot can be run locally with: 44 | 45 | ```sh 46 | # Install dependencies 47 | npm install 48 | 49 | # Run the bot 50 | npm start 51 | ``` 52 | 53 | More knowledge on building GitHub apps 54 | [here](https://developer.github.com/apps/building-your-first-github-app/). 55 | 56 | ## Contributing 57 | 58 | If you have suggestions for how the Dojo coach could be improved, or want to 59 | report a bug, open an 60 | [issue](https://github.com/dxc-technology/online-devops-dojo/issues/new/choose) 61 | or a PR! We'd love all and any contributions. 62 | 63 | ## Roadmap 64 | 65 | We are interested in adding the following features in the future: 66 | 67 | - Replace the GitHub app / Lambda function by a GitHub action. This would remove 68 | dependencies, but will it be responsive enough? 69 | - Add a test pipeline. 70 | -------------------------------------------------------------------------------- /handler.js: -------------------------------------------------------------------------------- 1 | // AWS lambda function handler.js 2 | // This Source Code Form is subject to the terms of the Mozilla Public 3 | // License, v. 2.0. If a copy of the MPL was not distributed with this 4 | // file, you can obtain one at http://mozilla.org/MPL/2.0/. 5 | 6 | const { serverless } = require('@probot/serverless-lambda') 7 | const appFn = require('./') 8 | module.exports.probot = serverless(appFn) 9 | -------------------------------------------------------------------------------- /online-devops-dojo-pathway.json: -------------------------------------------------------------------------------- 1 | { 2 | "title": "Online DevOps Dojo", 3 | "description": "Learning DevOps, for real. DXC Technology has long embraced the importance of DevOps. We have used multiple Katacoda scenarii to help transform our workforce at scale. We now want via the Online DevOps Dojo to contribute something to the community from whom we have learnt so much.", 4 | "courses": [ 5 | { 6 | "title": "Welcome", 7 | "description": "Getting started with the Online DevOps Dojo: understanding the back story, setting up your environment.", 8 | "course_id": "welcome" 9 | }, 10 | { 11 | "title": "Leading Change", 12 | "description": "Learn about the importance of Leading Change in DevOps Transformations. A large factor in the success of DevOps transformations is driven by the organization's ability to empower people to lead change at the different levels in the organization.", 13 | "course_id": "leading-change" 14 | }, 15 | { 16 | "title": "Version Control", 17 | "description": "Version control is a system that records changes to a file or set of files over time so that you can recall specific versions later.", 18 | "course_id": "version-control" 19 | }, 20 | { 21 | "title": "Continuous Integration", 22 | "description": "The process of merging work from all the developers in a team into the master branch as and when required.", 23 | "course_id": "continuous-integration" 24 | }, 25 | { 26 | "title": "Shift Left on Security", 27 | "description": "Security must be considered from the beginning and continuously assessed.", 28 | "course_id": "shift-security-left" 29 | }, 30 | { 31 | "title": "Value Stream Mapping", 32 | "description": "Learn how Value Stream Mapping can be used to help you and your team optimize your processes for value delivery and speed.", 33 | "course_id": "value-stream-mapping" 34 | }, 35 | { 36 | "title": "DevOps Kaizen", 37 | "description": "DevOps Kaizen events can be used to help you and your team continuously improve your development processes.", 38 | "course_id": "devops-kaizen" 39 | }, 40 | { 41 | "title": "Post Incident Practices", 42 | "description": "Learn how to establish a Safety Culture, conduct blameless post-mortems and create a “code of conduct” to help your team manage incidents in all phases of their life cycle", 43 | "course_id": "post-incident-practices" 44 | } 45 | ] 46 | } 47 | -------------------------------------------------------------------------------- /online-devops-dojo/continuous-integration/assets/index.html: -------------------------------------------------------------------------------- 1 | 2 |
3 | 4 | 5 | 7 | 27 |
28 | 29 | 30 |
31 |

GitHub links

32 |
33 |

Pet Clinic Repository

34 | github_url 35 |
36 |
37 |

User story

38 | github_url/issues 39 |
40 |
41 |

data.sql

42 | github_url/src/main/resources/db/hsqldb/data.sql#L51 44 |
45 |
46 |

Pull requests

47 | github_url/pulls 48 |
49 |
50 |

Web hook

51 | github_url/settings/hooks 52 |
53 |
54 |

Commits history

55 | github_url/commits/master 56 |
57 |
58 | 59 | 60 | -------------------------------------------------------------------------------- /online-devops-dojo/continuous-integration/finish.md: -------------------------------------------------------------------------------- 1 | # Conclusion 2 | 3 | You experienced a complete "Continuous Integration" flow: 4 | 5 | * Proposing changes within a short lived feature branch. 6 | * Submit a pull request. 7 | * Trigger the Continuous Integration pipeline. 8 | * Got the results from automated tests and checks. 9 | * Looked for feedback with a peer review. 10 | * Iterate on the change. 11 | * Finally, merge the change in the `master` branch. 12 | -------------------------------------------------------------------------------- /online-devops-dojo/continuous-integration/index.json: -------------------------------------------------------------------------------- 1 | { 2 | "pathwayTitle": "Online DevOps Dojo", 3 | "private": true, 4 | "title": "Continuous Integration", 5 | "description": "Experience continuous integration, the process of merging work from all the developers in a team into the master branch as and when required.", 6 | "difficulty": "intermediate", 7 | "time": "40 minutes", 8 | "details": { 9 | "steps": [ 10 | { 11 | "title": "Preparation", 12 | "text": "step1.md", 13 | "verify": "step1-verify.sh" 14 | }, 15 | { 16 | "title": "Jenkins dashboard", 17 | "text": "step2.md" 18 | }, 19 | { 20 | "title": "Work on a user story", 21 | "text": "step3-nospell.md" 22 | }, 23 | { 24 | "title": "Create a pull request", 25 | "text": "step4.md" 26 | }, 27 | { 28 | "title": "Jenkins pipeline execution", 29 | "text": "step5.md" 30 | }, 31 | { 32 | "title": "Rework the code", 33 | "text": "step6.md" 34 | }, 35 | { 36 | "title": "Someone else reviews the pull request", 37 | "text": "step7.md" 38 | }, 39 | { 40 | "title": "Merge to master branch", 41 | "text": "step8.md" 42 | } 43 | ], 44 | "intro": { 45 | "text": "intro.md" 46 | }, 47 | "assets": { 48 | "host01": [ 49 | {"file": "prepare.sh", "target": "~/","chmod": "+x"}, 50 | {"file": "index.html", "target": "~/nginx"} 51 | ] 52 | }, 53 | "finish": { 54 | "text": "finish.md" 55 | } 56 | }, 57 | "environment": { 58 | "hideintro": false, 59 | "uilayout": "terminal-iframe", 60 | "showdashboard": true, 61 | "dashboards": [ 62 | { "name": "GitHub", "port": 9876}, 63 | { "name": "Pet Clinic", "port": 9966} 64 | ], 65 | "uimessage1": "\u001b[32mYour Interactive Bash Terminal.\r\nYou can type in and run shell commands here.\r\n\u001b[m" 66 | }, 67 | "backend": { 68 | "imageid": "devopsdojo-jenkins-yb" 69 | } 70 | } 71 | -------------------------------------------------------------------------------- /online-devops-dojo/continuous-integration/intro.md: -------------------------------------------------------------------------------- 1 | ## Welcome! 2 | 3 | Welcome to the **Online DevOps Dojo** lab on Continuous Integration. 4 | If you have not completed the Welcome **and** Version Control modules you must 5 | do so before continuing with this module. 6 | 7 | ## The story 8 | 9 | **Previously**, Dan the developer 10 | 11 | ![](../../assets/online-devops-dojo/continuous-integration/dan.png) 12 | 13 | and his peers on the team, worked away developing business features on separate 14 | branches for up to weeks at a time. When the feature was complete they would 15 | commit their work to the central source code management system. Typically this 16 | was followed by 1 to 2 days integration phase as the release manager was 17 | gathering and merging the changes from all the team members. This was taking 18 | time and involved a lot of rework, merge conflicts which took time to be 19 | resolve, and often resulted in unplanned activities. To be able to produce 20 | deployable packages out of the code, they had to have a "code freeze" phase 21 | until a working build could be sent to QA/Testing. 22 | 23 | ![](../../assets/online-devops-dojo/continuous-integration/tina.png) 24 | 25 | Testing led by Tina would then proceed to identify issues with the development 26 | team having to fix the bugs before they could release the application to the 27 | business. 28 | 29 | **Now**, Dan's team applies the principle of working in small batches and 30 | building quality with continuous integration supported by a high degree of 31 | automated testing. All the developers are now continuously integrating to trunk 32 | (master branch) frequently. They use short lived (one to several days) feature 33 | branches which are quickly merged to master. Each and every commit triggers the 34 | continuous integration pipeline automatically, which builds the code and run 35 | automated tests created by Tina and the testing team. The pass/fail results are 36 | made available as part of the feature branch / pull request, thus detecting 37 | regressions automatically as well as providing accurate feedback to the 38 | development team. Dan (or the lead reviewing the pull request) will not merge 39 | the request to master if any of the checks ran from the continuous integration 40 | pipeline are not passing. 41 | 42 | This is **Continuous Integration** and it is proved to be a game changer for the 43 | software industry. 44 | -------------------------------------------------------------------------------- /online-devops-dojo/continuous-integration/step1-verify.sh: -------------------------------------------------------------------------------- 1 | #!/bin/bash 2 | 3 | [ -f /tmp/jenkins_ready ] && echo "done" -------------------------------------------------------------------------------- /online-devops-dojo/continuous-integration/step1.md: -------------------------------------------------------------------------------- 1 | Run the following command to bring up Jenkins and connect it to your copy of the 2 | Pet Clinic application's code. This script may take a few minutes to run. 3 | 4 | (you will re-use the GitHub "Personal Access Token" you have created in the 5 | Welcome module. If you lost it, go to 6 | [https://github.com/settings/tokens](https://github.com/settings/tokens) to 7 | create a new one and save it for later.) 8 | 9 | `./prepare.sh`{{execute}} 10 | 11 | ...and wait for the "Click on 'CONTINUE'" message. 12 | 13 | ✏ Note: **Jenkins** is an open source automation server used for automating 14 | continuous integration and facilitating the technical aspects of continuous 15 | delivery. 16 | 17 | 💡 **TIP**: 🦊 Firefox user? Use CTRL+INS / 18 | SHIFT+INS to copy/paste your Personal Access Token in the 19 | window. 20 | -------------------------------------------------------------------------------- /online-devops-dojo/continuous-integration/step2.md: -------------------------------------------------------------------------------- 1 | * Now that Jenkins is ready, open the Jenkins admin dashboard: 2 | https://[[HOST_SUBDOMAIN]]-8080-[[KATACODA_HOST]].environments.katacoda.com/blue/organizations/jenkins/ 4 | * Authenticate with the user `admin`{{copy}}, password 5 | `569747beeffb19d5cad165c7907b6471`{{copy}} 6 | 7 | Note: You may need to wait a few minutes until Jenkins finishes initializing and 8 | the login screen is displayed. 9 | -------------------------------------------------------------------------------- /online-devops-dojo/continuous-integration/step3-nospell.md: -------------------------------------------------------------------------------- 1 | As Dan the developer 2 | 3 | ![](../../assets/online-devops-dojo/continuous-integration/dan.png) 4 | 5 | you are working on the user story which was prioritized by Paulo, the product 6 | owner. 7 | 8 | ![](../../assets/online-devops-dojo/continuous-integration/paulo.png) 9 | 10 | ![](../../assets/online-devops-dojo/continuous-integration/user-story.png) 11 | 12 | The user story is visible as a GitHub issue in your GitHub repo: 13 | [https://github.com/[your_username]/pet-clinic/issues](https://[[HOST_SUBDOMAIN]]-9876-[[KATACODA_HOST]].environments.katacoda.com/#user-story) 14 | 15 | In the context of that user story which we started earlier, we need to add 16 | entries in the Pet Clinic database to add new pet names. 17 | 18 | # Add new pet names in the database 19 | 20 | You are about to modify the Pet Clinic code. In the Version Control module, we 21 | used the git client in the terminal window. In this module, you will use another 22 | method, through GitHub's web interface. 23 | 24 | * Head over to your copy of the Pet Clinic application on GitHub, and navigate 25 | to the file in the 26 | [`src/main/resources/db/hsqldb`](https://[[HOST_SUBDOMAIN]]-9876-[[KATACODA_HOST]].environments.katacoda.com/#datasql) 27 | folder named `data.sql`. This file is used to populate the application 28 | database with data when the pet clinic application is started 29 | * Click on the pencil icon in the top right corner to edit the file 30 | * Below `INSERT INTO pets VALUES (13, 'Sly', '2012-06-08', 1, 10);` around line 51, add two new lines for individual horses: 31 | 
32 | 
33 |   INSERT INTO pets VALUES (14, 'Jolly Jumper', '2012-09-20', 7, 5;
34 |   INSERT INTO pets VALUES (15, 'Flycka', '2012-07-14', 7, 9);
35 |
36 | * Do not save or commit your changes yet! 37 | 38 | **NOTE**: Yes, there is an error on the "Jolly Jumper" line - well done if you 39 | catch it! This is on purpose, so that you can see the checks which are 40 | automatically performed during continuous integration. 41 | -------------------------------------------------------------------------------- /online-devops-dojo/continuous-integration/step4.md: -------------------------------------------------------------------------------- 1 | ## Tasks 2 | 3 | * Under "**Commit changes**", enter a short description for the change. A good 4 | practices is to have the ID of the user story associated with this task in the 5 | short description like so: `Fix #1: add horse names in database`{{copy}} - for 6 | user story #1. 7 | * Choose "Create a **new branch** for this commit [...]" option and give the 8 | branch a meaningful short name such as `us-1-horse-db`{{copy}}. Note that the 9 | user story ID is used again in the branch name: this is to foster traceability 10 | and help maintain a clean history of commits to the repository. 11 | * Click "**Propose File Change**": this will trigger the creation of a pull 12 | request. 13 | * Scroll down and review the changes. You see a before and after comparison. 14 | * When you are happy with your changes click "**Create Pull Request**". 15 | -------------------------------------------------------------------------------- /online-devops-dojo/continuous-integration/step5.md: -------------------------------------------------------------------------------- 1 | ## Continuous Integration runs 2 | 3 | Go to Jenkins to see Continuous Integration happening: https://[[HOST_SUBDOMAIN]]-8080-[[KATACODA_HOST]].environments.katacoda.com/blue/organizations/jenkins/pet-clinic/activity/ 4 | 5 | ![CI Pipeline in Jenkins](../../assets/online-devops-dojo/continuous-integration/ci-blue-ocean.png) 6 | 7 | This will take some time to: 8 | 9 | * Download the dependencies of the Pet Clinic application. 10 | * Build the application to generate a package. 11 | * Run unit tests. 12 | * Deploy the result to an ephemeral Docker container. 13 | 14 | ## The mechanics 15 | 16 | As the pull request is created, a series of automated actions happen in the 17 | background: 18 | 19 | * GitHub notifies Jenkins of the code change thanks to the 20 | [web hook](https://help.github.com/articles/about-webhooks/), which you can 21 | see in your repository settings at 22 | [https://github.com/[your_username]/pet-clinic/settings/hooks](https://[[HOST_SUBDOMAIN]]-9876-[[KATACODA_HOST]].environments.katacoda.com/#hooks). 23 | A web hook is used to notify other applications about events in the GitHub 24 | repository, such as a Pull Request being submitted. 25 | * Jenkins reads the content of the 26 | [`Jenkinsfile`](https://jenkins.io/doc/book/pipeline/jenkinsfile/) at the root 27 | of your repository. The Jenkinsfile is the file which has the implementation 28 | of your applications' continuous integration pipeline. 29 | * The stages and steps in the Jenkinsfile are executed on the Jenkins server. 30 | 31 | ## Tasks 32 | 33 | * Review the result of the pipeline: note the "build" step has caught the error 34 | we introduced in a previous step. 35 | * Click on the step which is in error and review the logs of the error. 36 | -------------------------------------------------------------------------------- /online-devops-dojo/continuous-integration/step6.md: -------------------------------------------------------------------------------- 1 | ## Tasks 2 | 3 | The pipeline found an error which we need to fix. We are going to add new changes (commits) in the existing pull request to fix the error. 4 | 5 | * Open GitHub pull requests in your repository: [https://github.com/[your_username]/pet-clinic/pulls](https://[[HOST_SUBDOMAIN]]-9876-[[KATACODA_HOST]].environments.katacoda.com/#pr) 6 | * Open the pull request you have in progress. 7 | * In "Files changed" tab, click on ... right to `data.sql` file, then Edit file. 8 | * Around line 51, replace the "Jolly Jumper" line with the following line: `INSERT INTO pets VALUES (14, 'Jolly Jumper', '2012-09-20', 7, 5);`{{copy}} 9 | * In the "Commit changes" summary, enter a comment such as `Fix parenthesis`{{copy}} 10 | * Commit the code, into the same branch (for example `us-1-horse-db`). 11 | 12 | At this point, the Jenkins pipeline will be triggered again. It will again 13 | compile the code, run the automated tests and give the pass/fail verdict within 14 | the pull request. 15 | 16 | * Go to Jenkins to see the continuous integration pipeline execution. 17 | -------------------------------------------------------------------------------- /online-devops-dojo/continuous-integration/step7.md: -------------------------------------------------------------------------------- 1 | At this point, because you have fixed the only open issue all the automated checks will have passed. 2 | 3 | It is now time to involve someone else for a peer review. 4 | 5 | ## Tasks 6 | 7 | ![](../../assets/online-devops-dojo/continuous-integration/tina.png) 8 | 9 | * In the pull request, add a comment to ask Tina the tester to review the pull request: `/tina - can you have a look at this?`{{copy}} 10 | * After checking the changes in the "Files changed" tab, Tina will have comments, and wants you to replace "Jolly Jumper" by "Silver Blaze", around line 51. 11 | * Go ahead and implement the change by clicking the pen icon in the "Files changed" tab next to `data.sql` file, in the context of the existing - still opened - pull request. 12 | * Jenkins will again build and test the entire application with this latest change, making sure everything builds and tests are passing. Check it at: https://[[HOST_SUBDOMAIN]]-8080-[[KATACODA_HOST]].environments.katacoda.com/blue/organizations/jenkins/pet-clinic/pr 13 | * If everything is OK, the tests will pass. The pull request displays the checks done by Jenkins: everything is green! 14 | -------------------------------------------------------------------------------- /online-devops-dojo/continuous-integration/step8.md: -------------------------------------------------------------------------------- 1 | It is time to involve Tina again, as build and automated tests are passing: 2 | 3 | * Ask Tina to have another look by adding a comment in the pull request: 4 | `/tina - done.`{{copy}} 5 | * Tina will review and comment positively on the changes. 6 | * Merge the pull request by clicking the "Merge pull request" button. 7 | * Delete the branch `us-1-horse-db`. 8 | 9 | Now that you have merged the pull request, the new code is merged to the 10 | `master` branch, making it usable by the rest of the team. 11 | 12 | You can see the history of the changes at [https://github.com/[your_username]/pet-clinic/commits/master](https://[[HOST_SUBDOMAIN]]-9876-[[KATACODA_HOST]].environments.katacoda.com/#commits) 13 | 14 | * Check the pet clinic app, which has been automatically deployed by Jenkins: 15 | [pet-clinic app](https://[[HOST_SUBDOMAIN]]-9966-[[KATACODA_HOST]].environments.katacoda.com/) 16 | * Click the "Find Owners" tab, leave "last name" field blank and click "Find 17 | owner" button. 18 | * Check that you can find owners with the horses you added in the database. 19 | * Select an owner, and click "Add New Pet". 20 | * Check that you can add find "horse" and "pony" in the "Type" drop down list. 21 | * Feel free to explore more and modify the code at will, to see Continuous 22 | Integration being kicked off automatically, for every code commit. 23 | 24 | ## Conclusion 25 | 26 | You have integrated ("continuous integration") your own code with the rest of 27 | the code base. 28 | 29 | While you were fixing issues you introduced and had a discussion with Tina, none 30 | of your changes impacted the rest of the team, although they were visible for 31 | anyone in the team to review. 32 | -------------------------------------------------------------------------------- /online-devops-dojo/devops-kaizen/assets/add.improvement.to.backlog.sh: -------------------------------------------------------------------------------- 1 | #!/bin/bash 2 | # This Source Code Form is subject to the terms of the Mozilla Public 3 | # License, v. 2.0. If a copy of the MPL was not distributed with this 4 | # file, You can obtain one at https://mozilla.org/MPL/2.0/. 5 | # 6 | # Globals 7 | # 8 | DEBUG=false 9 | GITHUB='github.com' 10 | GITHUBAPIURL='https://api.github.com' 11 | # Explicit header for GitHub API V3 request cf. https://developer.github.com/v3/#current-version 12 | GITHUBAPIHEADER='Accept: application/vnd.github.v3+json' 13 | 14 | COLQUESTION="\u001b[36m" 15 | COLINFO="\u001b[37m" 16 | COLLOGS="\u001b[35m" 17 | COLRESET="\u001b[m" 18 | REPO=pet-clinic 19 | ORGREPO=dxc-technology 20 | 21 | if [ "$DEBUG" = false ] ; then 22 | CURL_NODEBUG="-sS" 23 | fi 24 | 25 | # Install Python pre-req 26 | echo -e "${COLINFO}Installing dependencies...${COLRESET}" 27 | 2>/dev/null 1>/dev/null python3 -m pip install pyyaml requests 28 | 29 | # adding -s to the command line, allows to hide the PAT entered especially during demos 30 | if [ "$1" == "-s" ] ; then 31 | HIDE_PAT="-s" 32 | fi 33 | 34 | # 35 | # Ask for GitHub PAT 36 | # 37 | echo -e "${COLQUESTION}Please enter your ${GITHUB} Personal Access Token:${COLRESET}" 38 | read $HIDE_PAT TOKEN 39 | export TOKEN 40 | 41 | check_credentials() 42 | { 43 | curl $CURL_NODEBUG -H "Authorization: token $TOKEN" -H "$GITHUBAPIHEADER" -X GET ${GITHUBAPIURL} | grep "current_user_url" 44 | CREDS_NOT_OK=$? 45 | if [ $CREDS_NOT_OK -ne 0 ]; then 46 | echo -e "${COLQUESTION}Error: it seems that your credentials are invalid. Please use your GitHub user account and a Personal Access Token with 'repo' and 'admin:repo_hook' scopes at https://github.com/settings/tokens/new ${COLRESET}" 47 | exit -1 48 | fi 49 | } 50 | check_credentials 51 | 52 | echo -e "${COLLOGS}Fetching your details from GitHub...${COLRESET}" 53 | USER_JSON=$(curl ${CURL_NODEBUG} -H "Authorization: token ${TOKEN}" -H "$GITHUBAPIHEADER" -X GET ${GITHUBAPIURL}/user) 54 | 55 | SHORTNAME=$(echo $USER_JSON | jq -r '.login') 56 | export SHORTNAME 57 | 58 | # Provision user stories in GitHub 59 | python3 ./github-issues.py github-issues.yaml 60 | 61 | echo -e "${COLINFO}Improvement theme added to the backlog: https://${GITHUB}/${SHORTNAME}/pet-clinic/issues${COLRESET}" 62 | 63 | touch /tmp/userstoriesadded.txt 64 | -------------------------------------------------------------------------------- /online-devops-dojo/devops-kaizen/assets/dialog1.sh: -------------------------------------------------------------------------------- 1 | #!/bin/bash 2 | 3 | # clear the screen 4 | clear 5 | 6 | # 7 | # Globals 8 | # 9 | COLINFO="\u001b[37m" 10 | COLRESET="\u001b[m" 11 | 12 | echo -e "${COLINFO}Installing dependencies...${COLRESET}" 13 | 14 | # Install python pre-reqs 15 | 2>/dev/null 1>/dev/null python3 -m pip install pyyaml 16 | 17 | #play the dialog 18 | TERM=xterm-256color python3 dialog.py dialog1.yaml 19 | 20 | clear 21 | echo "Click on 'CONTINUE'." 22 | -------------------------------------------------------------------------------- /online-devops-dojo/devops-kaizen/assets/dialog1.yaml: -------------------------------------------------------------------------------- 1 | --- 2 | speaking: Brenda 3 | text: > 4 | When I worked in the Robotic Pets Assembly Plant we ran improvement events, you may recall I mentioned the similarities of those events to the VSM exercise we conducted. 5 | --- 6 | speaking: Santhosh 7 | text: > 8 | We do, indeed some of your contributions based on that experience greatly helped with the VSM. 9 | --- 10 | speaking: Brenda 11 | text: > 12 | Cheers, so I presume to host the DevOps Kaizen events we need to organize something similar to those meetings, set aside a few days for the Kaizen planning, document the outcomes, assemble a team with a view to identifying and scheduling the improvements we want to make to our process? 13 | --- 14 | speaking: Paulo 15 | text: > 16 | In principle yes, but I want to embed Kaizen into the fabric of our processes or day to day operations if you will. 17 | --- 18 | speaking: Selma 19 | text: > 20 | Sounds like you have a plan, care to share? 21 | --- 22 | speaking: Paulo 23 | text: > 24 | Of course, the VSM confirmed what most of us already knew. Our process is flawed and it needs to be improved, agree? 25 | --- 26 | speaking: Selma 27 | text: > 28 | Yes. 29 | --- 30 | speaking: Paulo 31 | text: > 32 | We have already started that change with the introduction of Agile. Kudos to Santhosh and team for those efforts. Dan has been suggesting we move towards DevOps, and that too is underway with Chun supporting as the DevOps coach. 33 | --- 34 | speaking: Paulo 35 | text: > 36 | I want to incorporate Kaizen Events into those initiatives. 37 | --- 38 | speaking: Adam 39 | text: > 40 | I like where this is going. What do you see as the main advantage to this approach? 41 | --- 42 | speaking: Paulo 43 | text: > 44 | I will let Chun answer that question. 45 | --- 46 | speaking: Chun 47 | text: > 48 | In a sentence it would be that continuous improvement would become part of our daily work, that it becomes second nature to us in all stages of our development cycle including architecture, planning, development, testing, security, deployment and operability. 49 | --- 50 | speaking: Tina 51 | text: > 52 | Count me in. 53 | --- 54 | speaking: Dan 55 | text: > 56 | Me too. 57 | --- 58 | speaking: Brenda 59 | text: > 60 | Putting my business hat on, I have to ask my two favorite questions of the team. When can we start? And when will we start to see the improvements? 61 | --- 62 | speaking: Paulo 63 | text: > 64 | No time like the present. 65 | --- 66 | speaking: Santhosh 67 | text: > 68 | Great but before we proceed, let's ask some questions to [student]. 69 | -------------------------------------------------------------------------------- /online-devops-dojo/devops-kaizen/assets/dialog2.sh: -------------------------------------------------------------------------------- 1 | #!/bin/bash 2 | 3 | # clear the screen 4 | clear 5 | 6 | #play the dialog 7 | TERM=xterm-256color python3 dialog.py dialog2.yaml 8 | 9 | clear 10 | echo "Click on 'CONTINUE'." 11 | -------------------------------------------------------------------------------- /online-devops-dojo/devops-kaizen/assets/dialog2.yaml: -------------------------------------------------------------------------------- 1 | --- 2 | speaking: Santhosh 3 | text: > 4 | Welcome to our first DevOps Kaizen event. 5 | --- 6 | speaking: Dan 7 | text: > 8 | Thanks Santhosh, how are we to approach this session? 9 | --- 10 | speaking: Santhosh 11 | text: > 12 | We know Improvements are needed, and that we can't change everything at the same time so we need to identify some focus areas based on the VSM. 13 | --- 14 | speaking: Selma 15 | text: > 16 | I have been proposing a Shift Left on Security for some time, can that be one? 17 | --- 18 | speaking: Tina 19 | text: > 20 | Dan and I have been discussing increasing the use of test automation, can we look at that? 21 | --- 22 | speaking: Adam 23 | text: > 24 | Tina and Selma, I think both of those are needed and what's more I think they would fit nicely with some ideas I have around Source Code Management, Continuous Integration and Continuous Deployment. 25 | --- 26 | speaking: Chun 27 | text: > 28 | Guys, guys, great ideas but we can't boil the ocean. Can we look at these suggestions, prioritize them based on expected value and time to implement with a view to incorporating them in to an Improvement Theme? 29 | --- 30 | speaking: Dan 31 | text: > 32 | I think so, especially as they are all inter-related, as Adam pointed out. They all will help facilitate flow and eliminate waste in our development process. 33 | --- 34 | speaking: Chun 35 | text: > 36 | Exactly! Automated testing, automated security scans, version control, and CI/CD will allow problems to be identified earlier and feedback amplified as per the three ways of DevOps. 37 | --- 38 | speaking: Paulo 39 | text: > 40 | Agree, but think we also need to be mindful of the metrics we collected during the VSM exercise which were lead time, processing time, and %C/A when prioritizing the next steps for the Improvement Theme. 41 | --- 42 | speaking: Santhosh 43 | text: > 44 | I agree, being able to track progress against key metrics will help us quantify the progress we make and prioritize items for inclusion in the themes. 45 | --- 46 | speaking: Tina 47 | text: > 48 | We may need more than one Improvement Theme given the breadth and scale of the issues we are trying to address. 49 | --- 50 | speaking: Paulo 51 | text: > 52 | That is fine, after all the resulting work will eventually be tracked in our Agile tool under the DevOps Kaizen epic we created. That will give us the holistic view of the improvements underway. 53 | -------------------------------------------------------------------------------- /online-devops-dojo/devops-kaizen/assets/github-issues.py: -------------------------------------------------------------------------------- 1 | #!/usr/bin/python3 2 | # Python helper to create GitHub issues, except if they already exist 3 | 4 | # This Source Code Form is subject to the terms of the Mozilla Public 5 | # License, v. 2.0. If a copy of the MPL was not distributed with this 6 | # file, You can obtain one at https://mozilla.org/MPL/2.0/. 7 | 8 | import os, sys, json, requests, yaml 9 | 10 | # Color constants 11 | # Reference: https://gist.github.com/chrisopedia/8754917 12 | COLINFO="\033[0;35m" 13 | COLRESET="\033[m" 14 | 15 | baseurl = 'https://api.github.com' 16 | headers = {"Content-Type": "application/json", "Accept": "application/vnd.github.v3+json"} 17 | user = os.environ['SHORTNAME'] 18 | token = os.environ['TOKEN'] 19 | repo = user + '/pet-clinic' 20 | 21 | if len(sys.argv) != 2: 22 | print(" Usage: " + sys.argv[0] + " github-issues.yaml") 23 | sys.exit(0) 24 | 25 | def main(): 26 | print(COLINFO + "Create user stories as GitHub issues..." + COLRESET) 27 | 28 | # Command line argument: issues as yaml file 29 | issues_file = sys.argv[1] 30 | 31 | # read the issues 32 | try: 33 | issues = yaml.load_all(open(issues_file, 'r'), Loader=yaml.FullLoader) 34 | except yaml.YAMLError as exc: 35 | print(COLINFO + exc + COLRESET) 36 | 37 | # Create the issues 38 | for issue in issues: 39 | # Avoid creating an issue which is already there (same title) 40 | issue_already_exists = False 41 | # List all open issues 42 | payload = json.dumps({ 43 | "state" : "open" 44 | }) 45 | sys.stdout.write(COLINFO + "." + COLRESET) 46 | sys.stdout.flush() 47 | response = requests.get(baseurl + "/repos/" + repo + "/issues", 48 | data=payload, 49 | headers=headers, 50 | auth=(user, token)) 51 | if response.status_code == 200: 52 | issues_opened = json.loads(response.text) 53 | for issue_found in issues_opened: 54 | if (issue_found['title'] == issue['title']): 55 | # This issue has the same title has the one we want to create. Skipping. 56 | issue_already_exists = True 57 | 58 | if (not issue_already_exists): 59 | payload = json.dumps({ 60 | "title" : issue['title'], 61 | "body": issue['body'], 62 | "labels" : issue['labels'] 63 | }) 64 | response = requests.post(baseurl + "/repos/" + repo + "/issues", 65 | data=payload, 66 | headers=headers, 67 | auth=(user, token)) 68 | if response.status_code != 201: 69 | # An error occured 70 | print(COLINFO + "Error adding issue " + issue['title'] + ": " + str(response.status_code) + " " + response.text + COLRESET) 71 | else: 72 | sys.stdout.write(COLINFO + "." + COLRESET) 73 | sys.stdout.flush() 74 | print(COLRESET) 75 | 76 | main() 77 | -------------------------------------------------------------------------------- /online-devops-dojo/devops-kaizen/assets/github-issues.yaml: -------------------------------------------------------------------------------- 1 | --- 2 | title: Implement Continuous Testing 3 | body: > 4 | From **Tina**: 5 | ![](https://s3.amazonaws.com/devopsdojoassets/tina.png) 6 | 7 | # DevOps Kaizen Improvement Theme 8 | 9 | ### **:green_book: Now / Current State** 10 | 11 | Testing is mostly manual, mainly performed after the development is completed, feedback on issues is too late in the process which in turn is leading to rework and delays 12 | 13 | ### **:star: Definition of awesome** 14 | 15 | Any code committed to our source code management system would be continuously integrated via a Jenkins pipeline. 16 | 17 | The pipeline would execute of a comprehensive set of automated tests (continuous testing) against the code, these tests would include unit tests that cover 70 to 80% of the code and automated acceptance tests of key functional areas. 18 | 19 | ### **:dart: Next target condition** 20 | 21 | Introduce Unit Testing and execute the unit tests from a CI pipeline. 22 | 23 | ### **:feet: First steps** 24 | 25 | Create the Pipeline, have it invoked when code is committed and execute some unit tests from the pipeline 26 | labels: [":sparkles: epic", "P3", "13"] 27 | --- 28 | title: Add functional testing stage in CI/CD pipeline 29 | body: "As part of improvement theme #[previous_issue]:\r\r **As a** tester,\r**I want** automated functional tests to be executed as part of the CI/CD pipeline for each and every code commit,\r**so that** we can get feedback on issues early in the process and avoid rework and delays." 30 | labels: [":bulb: user_story", "P1", "3"] 31 | -------------------------------------------------------------------------------- /online-devops-dojo/devops-kaizen/assets/prereq.sh: -------------------------------------------------------------------------------- 1 | #!/bin/bash 2 | # This Source Code Form is subject to the terms of the Mozilla Public 3 | # License, v. 2.0. If a copy of the MPL was not distributed with this 4 | # file, You can obtain one at https://mozilla.org/MPL/2.0/. 5 | 6 | COLQUESTION="\u001b[36m" 7 | COLRESET="\u001b[m" 8 | COLINFO="\u001b[37m" 9 | 10 | echo -e "${COLINFO}Installing dependencies...${COLRESET}" 11 | 2>/dev/null 1>/dev/null python3 -m pip install pyyaml 12 | 13 | # if learner doesn't enter name, default will be set in dialog.py 14 | echo "Please enter your first name:" 15 | read FIRSTNAME 16 | 17 | echo $FIRSTNAME > /tmp/firstname.txt 18 | 19 | echo -e "${COLINFO}You are all set! Click on 'CONTINUE'.${COLRESET}" 20 | -------------------------------------------------------------------------------- /online-devops-dojo/devops-kaizen/finish.md: -------------------------------------------------------------------------------- 1 | # Conclusion 2 | 3 | Congratulations, you have completed the DevOps Kaizen module of the **Online DevOps Dojo**! 4 | 5 | Before moving on to the next module in this course or going back to work please take a few minutes to consider how you and your team could apply DevOps Kaizen. 6 | -------------------------------------------------------------------------------- /online-devops-dojo/devops-kaizen/intro.md: -------------------------------------------------------------------------------- 1 | ## Welcome! 2 | 3 | Welcome to the **Online DevOps Dojo** lab on DevOps Kaizen. 4 | If you have not completed the Welcome module you must do so before continuing 5 | with this module. 6 | 7 | ## Purpose 8 | 9 | The primary objective of the "DevOps Kaizen" module is to help you to understand the principles and benefits of DevOps Kaizen. This is to enable you and your team to use DevOps Kaizen (Continuous Improvement) as both a framework and as a repeatable process to help empower your team. You will learn how DevOps Kaizen can be used to identify and fix issues with, and to continuously improve your Value Streams. 10 | 11 | The secondary objective is to give you an opportunity to participate in a DevOps Kaizen real world scenario using Katacoda in **your** Sandbox environment. 12 | 13 | Remember the Sandbox is your personal clone of the Pet Clinic Repository. The Sandbox is the one which you created in the Welcome module. You are free to experiment in your Sandbox without fear of impacting the lab or other learners. 14 | 15 | By the end of the lesson and lab, you will be able to 16 | 17 | Explain what a DevOps Kaizen is. 18 | 19 | * Describe the need for and business benefits of DevOps Kaizen 20 | * Understand the process of conducting a DevOps Kaizen event 21 | * who should participate 22 | * how to identify focus areas to improve from the Value Stream Map (VSM) 23 | * set measurable objectives 24 | * define the Kaizen increment (short period 2 to 3 weeks) 25 | * specify what success looks like so progress can be tracked against objectives 26 | * reassess improvements and objectives at the end of each increment 27 | * update target conditions based upon progress and learnings from the Kaizen event 28 | * Leverage DevOps/Lean toolbox of tools, technologies, practices and methodologies in a Kaizen increment. 29 | -------------------------------------------------------------------------------- /online-devops-dojo/devops-kaizen/step1.md: -------------------------------------------------------------------------------- 1 | While the DevOps Kaizen module can be taken independently, it follows directly 2 | on from the Value Stream Mapping module. 3 | 4 | Hopefully you have followed our advice and taken the Value Stream Mapping (VSM) 5 | module of the **Online DevOps Dojo** and are thus helping us in the serious 6 | business of protecting the space time continuum. 7 | 8 | This is the VSM which the Pet Clinic team created to represent the E2E flow of 9 | their development process: 10 | 11 | ![](../../assets/online-devops-dojo/devops-kaizen/valuestreammap.png) 12 | 13 | The team have gotten sponsorship from management to improve, and are now 14 | wondering how to leverage the VSM as the starting point. 15 | 16 | | | | 17 | |---|---| 18 | |![Chun](../../assets/online-devops-dojo/devops-kaizen/chun.png)|**Chun** DevOps coach for the DevOps Kaizen events | 19 | |![Paulo](../../assets/online-devops-dojo/devops-kaizen/paulo.png)|**Paulo** Product Owner who is sponsoring the DevOps Kaizen events | 20 | |![Santhosh](../../assets/online-devops-dojo/devops-kaizen/santhosh.png)|**Santhosh** Scrum Master who is facilitating the DevOps Kaizen events | 21 | |![Brenda](../../assets/online-devops-dojo/devops-kaizen/brenda.png)|**Brenda** Business representative in the DevOps Kaizen events | 22 | |![Selma](../../assets/online-devops-dojo/devops-kaizen/selma.png)|**Selma** Security representative in the DevOps Kaizen events | 23 | |![Adam](../../assets/online-devops-dojo/devops-kaizen/adam.png)|**Adam** IT Admin representative in the DevOps Kaizen events | 24 | |![Dan](../../assets/online-devops-dojo/devops-kaizen/dan.png)|**Dan** Developer representative in the DevOps Kaizen events | 25 | |![Tina](../../assets/online-devops-dojo/devops-kaizen/tina.png)|**Tina** Test representative in the DevOps Kaizen events | 26 | -------------------------------------------------------------------------------- /online-devops-dojo/devops-kaizen/step10-verify.sh: -------------------------------------------------------------------------------- 1 | #!/bin/bash 2 | 3 | [ -f /tmp/userstoriesadded.txt ] && echo "done" -------------------------------------------------------------------------------- /online-devops-dojo/devops-kaizen/step10.md: -------------------------------------------------------------------------------- 1 | 2 | The output of the DevOps Kaizen events are the Improvement Themes. 3 | 4 | ![](../../assets/online-devops-dojo/devops-kaizen/tina.png) 5 | 6 | Tina and the team came up with the following testing improvement theme: 7 | 8 | ## **Title**: Continuous Testing 9 | 10 | | ![](../../assets/online-devops-dojo/devops-kaizen/current-state.png) **Now/Problem** | ![](../../assets/online-devops-dojo/devops-kaizen/target.png) **Next Target Condition** | 11 | |---|---| 12 | | Testing is mostly manual, mainly performed after the development is completed, feedback on issues is too late in the process which in turn is leading to rework and delays | Introduce functional tests with Selenium and execute the tests from our CI pipeline | 13 | | ![](../../assets/online-devops-dojo/devops-kaizen/awesome.png) **Definition of Awesome** | ![](../../assets/online-devops-dojo/devops-kaizen/steps.png) **First Steps** | 14 | | Any code committed to our source code management system would be continuously integrated via a Jenkins pipeline.
The pipeline would execute of a comprehensive set of automated tests (continuous testing) against the code.
These tests would include unit tests that cover 70 to 80% of the code and automated acceptance tests of key functional areas. | Add a stage in our pipeline which includes automated functional tests. | 15 | 16 | ![](../../assets/online-devops-dojo/devops-kaizen/santhosh.png) 17 | 18 | Santhosh, as a good Scrum master, wants to have all the work prioritized in the 19 | agile backlog. So, let's add that improvement theme in our backlog: 20 | 21 | `./add.improvement.to.backlog.sh`{{execute}} 22 | 23 | **Note**: you will re-use GitHub's "Personal Access Token" you created in the 24 | Welcome module. If you need to generate a new one, go to 25 | [https://github.com/settings/tokens](https://github.com/settings/tokens) 26 | and save it for later. 27 | 28 | 💡 **TIP**: 🦊 Firefox user? Use CTRL+INS / 29 | SHIFT+INS to copy/paste your Personal Access Token in the 30 | window. 31 | -------------------------------------------------------------------------------- /online-devops-dojo/devops-kaizen/step11.md: -------------------------------------------------------------------------------- 1 | The team now have their DevOps Kaizen events up and running, they have the initial Improvement Themes defined and added to their backlog. 2 | 3 | They have a plan for the improvements to made over the next 3 sprints. They have user stories, with detailed acceptance criteria, written to track the work under the DevOps Kaizen epic added to their product backlog in their Agile tool. 4 | 5 | Due to the wonders of time travel, you the Learner can see the results of the DevOps Kaizen improvements the Pet Clinic team made over the past year in some of the other modules in this course including: 6 | 7 | - Version Control 8 | - Trunk Based Development 9 | - Continuous Integration 10 | - The Continuous Delivery Pipeline 11 | - Working in small batches 12 | - Test Driven Development 13 | - Continuous Testing / Test Automation 14 | - Shift Left on Security 15 | - Automated Deployment 16 | 17 | Fade out ... 18 | -------------------------------------------------------------------------------- /online-devops-dojo/devops-kaizen/step12-answer.md: -------------------------------------------------------------------------------- 1 | The correct answer is **False** 2 | 3 | A team can have many Improvement Themes active at any one time, the Next Steps agreed for each Improvement Theme should be used to create stories in the team's backlog. -------------------------------------------------------------------------------- /online-devops-dojo/devops-kaizen/step12.md: -------------------------------------------------------------------------------- 1 | >> True or False, a team should only have one Improvement Theme active at a time? << 2 | ( ) True 3 | (*) False 4 | -------------------------------------------------------------------------------- /online-devops-dojo/devops-kaizen/step13-answer.md: -------------------------------------------------------------------------------- 1 | The correct answer is **False** 2 | 3 | VSM is used to map current state while DevOps Kaizen drives continuous improvements in a process using DevOps tools and processes. -------------------------------------------------------------------------------- /online-devops-dojo/devops-kaizen/step13.md: -------------------------------------------------------------------------------- 1 | >> True or False, VSM and DevOps Kaizen are two different techniques to implement continuous improvements in a process? << 2 | ( ) True 3 | (*) False -------------------------------------------------------------------------------- /online-devops-dojo/devops-kaizen/step3-verify.sh: -------------------------------------------------------------------------------- 1 | #!/bin/bash 2 | 3 | [ -f /tmp/firstname.txt ] && echo "done" -------------------------------------------------------------------------------- /online-devops-dojo/devops-kaizen/step3.md: -------------------------------------------------------------------------------- 1 | The team have decided to run DevOps Kaizen events to continually and incrementally improve their process. 2 | 3 | The remainder of this lab is a series of conversational snippets taken at various points in the timeline of the planning and operation of the DevOps Kaizen events held by the Pet Clinic team. 4 | 5 | First before you continue, let's get your name: click `./prereq.sh`{{execute}} -------------------------------------------------------------------------------- /online-devops-dojo/devops-kaizen/step4-verify.sh: -------------------------------------------------------------------------------- 1 | #!/bin/bash 2 | 3 | [ -f /tmp/dialog1played.txt ] && echo "done" -------------------------------------------------------------------------------- /online-devops-dojo/devops-kaizen/step4.md: -------------------------------------------------------------------------------- 1 | 2 | ![](../../assets/online-devops-dojo/devops-kaizen/team-chat.jpg) 3 | 4 | Click: `./dialog1.sh`{{execute}} 5 | 6 | And follow the dialog in the terminal window... 7 | -------------------------------------------------------------------------------- /online-devops-dojo/devops-kaizen/step5-answer.md: -------------------------------------------------------------------------------- 1 | The correct answer is **Mapping the Value Stream** 2 | 3 | To start a DevOps Kaizen event you need to understand the current state and VSM provides that. 4 | -------------------------------------------------------------------------------- /online-devops-dojo/devops-kaizen/step5.md: -------------------------------------------------------------------------------- 1 | >> What is the recommended precursor to a DevOps Kaizen event? << 2 | (*) Mapping the Value Stream 3 | ( ) Selecting an Agile tool for Kanban management 4 | ( ) Defining Start and End points 5 | ( ) Agreeing Service Level Agreements for each step in the process -------------------------------------------------------------------------------- /online-devops-dojo/devops-kaizen/step6-answer.md: -------------------------------------------------------------------------------- 1 | The correct answers are **Ensuring stakeholder participation** and **A focus on identifying and eliminating waste** 2 | 3 | Ensuring stakeholder participation and A focus on identifying and eliminating waste are key factors in the formulation of a teams DevOps Kaizen Strategy. A BRD is not as a BRD is typically a contract between a development organization and their customer for the delivery of a service or a product. BRD's, assume the end state is known where as DevOps Kaizen events support continuous incremental improvements towards a desired end state. -------------------------------------------------------------------------------- /online-devops-dojo/devops-kaizen/step6.md: -------------------------------------------------------------------------------- 1 | >> Which of the following are key factors in the formulation of a teams DevOps Kaizen Strategy? << 2 | [*] Ensuring stakeholder participation 3 | [*] A focus on identifying and eliminating waste 4 | [ ] Having a Business Requirements Document (BRD) specifying the improvements the DevOps Kaizen will deliver 5 | [ ] All of the above 6 | -------------------------------------------------------------------------------- /online-devops-dojo/devops-kaizen/step7.md: -------------------------------------------------------------------------------- 1 | We rejoin the team after they have agreed to follow these high level steps based on industry best practices to implement their DevOps Kaizen cycle 2 | 3 | - Appoint a Kaizen facilitator 4 | - Ensure leadership and team are engaged 5 | - Assemble the Kaizen team 6 | - Set the scope and limits of the Kaizen Events 7 | - Assess current state and define success 8 | - Prepare and schedule the Kaizen events 9 | - Kick off Kaizen Cycle 10 | 11 | The team is engaged, assembled and excited to start. They are in the middle of working through the implementation plan. They have: 12 | 13 | - Obtained leadership support 14 | - Selected Chun as the DevOps coach. 15 | - Appointed Santhosh as the Kaizen facilitator. 16 | - Set the scope and limits of the Kaizen Event. 17 | - Decided on a 6 weeks Kaizen event cycle with 2 weeks increments and aligned them with the teams current sprint cycle. 18 | - Agreed to set time aside in the Scrum ceremonies to plan, discuss progress on and review DevOps Kaizen improvements. 19 | - Agreed that the work to implement the desired improvements will be managed via the teams' Agile Backlog. 20 | - Created an epic in their Agile tool to track the DevOps Kaizen user stories. 21 | - Appointed key team members. Adam, Dan, Tina and Selma have committed 20% of their time to the DevOps Kaizen implementation. 22 | 23 | They now need to assess current state and define success as well as to prepare, schedule and kick of the Kaizen Cycle. 24 | 25 | Chun suggests the use of Improvement Themes to assess current state and define success 26 | 27 | ![](../../assets/online-devops-dojo/devops-kaizen/improvementtheme.jpg) 28 | 29 | and explains that the Improvement Theme consists of five areas. 30 | 31 | 1. Improvement Theme Name 32 | 2. Now/Problem – Description of the current state 33 | 3. Definition of Awesome – The desired state 34 | 4. Next Target Condition – X weeks from now, what will have changed? 35 | 5. First Steps – 3 slots which describe the first steps to be taken to address the delta between current and desired state 36 | 37 | She further explains that the Improvement Theme should be a living document accessible to all stakeholders. The core Kaizen team should review the Improvement Theme once or twice per week, updating the theme based on completed and new identified actions. 38 | -------------------------------------------------------------------------------- /online-devops-dojo/devops-kaizen/step8-answer.md: -------------------------------------------------------------------------------- 1 | The incorrect answer is **Delta between Current and Desired State** 2 | 3 | Delta between Current and Desired State is not a section in an Improvement Theme, an Improvement Theme does however include a section entitled First Steps which contains 3 slots to describe the first steps to be taken to address the delta between current and desired state -------------------------------------------------------------------------------- /online-devops-dojo/devops-kaizen/step8.md: -------------------------------------------------------------------------------- 1 | >> Which of the following is not a section in an Improvement Theme? << 2 | ( ) Now/Problem 3 | ( ) Next Target Condition 4 | ( ) Delta between Current and Desired State 5 | ( ) Definition of Awesome -------------------------------------------------------------------------------- /online-devops-dojo/devops-kaizen/step9-verify.sh: -------------------------------------------------------------------------------- 1 | #!/bin/bash 2 | 3 | [ -f /tmp/dialog2played.txt ] && echo "done" -------------------------------------------------------------------------------- /online-devops-dojo/devops-kaizen/step9.md: -------------------------------------------------------------------------------- 1 | 2 | ![](../../assets/online-devops-dojo/devops-kaizen/team-chat.jpg) 3 | 4 | We rejoin the team in the first DevOps Kaizen event. 5 | 6 | Click: `./dialog2.sh`{{execute}} 7 | 8 | And follow the dialog in the terminal window... -------------------------------------------------------------------------------- /online-devops-dojo/leading-change/assets/dialog1.sh: -------------------------------------------------------------------------------- 1 | #!/bin/bash 2 | 3 | # clear the screen 4 | clear 5 | 6 | #play the dialog 7 | TERM=xterm-256color python3 dialog.py dialog1.yaml 8 | 9 | echo "Click on 'CONTINUE'." 10 | -------------------------------------------------------------------------------- /online-devops-dojo/leading-change/assets/dialog2.sh: -------------------------------------------------------------------------------- 1 | #!/bin/bash 2 | 3 | # clear the screen 4 | clear 5 | 6 | #play the dialog 7 | TERM=xterm-256color python3 dialog.py dialog2.yaml 8 | 9 | echo "Click on 'CONTINUE'." 10 | -------------------------------------------------------------------------------- /online-devops-dojo/leading-change/assets/dialog2.yaml: -------------------------------------------------------------------------------- 1 | --- 2 | speaking: Santhosh 3 | text: > 4 | This all sounds wonderful, but how do we start? 5 | --- 6 | speaking: Chun 7 | text: > 8 | In one sentence by assessing current state, defining what awesome would look like, and putting a plan in place to incrementally address any deltas identified between current state and awesome. 9 | --- 10 | speaking: Paulo 11 | text: > 12 | I am reminded of the old quote "When eating an elephant take one bite at a time." 13 | --- 14 | speaking: Chun 15 | text: > 16 | Exactly. In our case each bite would be comprised of a two week continuous improvement event. These events are also known as DevOps Kaizen events. But I am getting ahead of myself. Let me answer Santhosh's question first. 17 | --- 18 | speaking: Chun 19 | text: > 20 | Santhosh, we would start by assessing current state of the development process using Value Stream Mapping (VSM). 21 | --- 22 | speaking: Chun 23 | text: > 24 | VSM will give us a shared understanding of the current process, with some key process metrics for each step in the process. These metrics would include lead time, processing time and % C/A which is the % complete versus accurate work received by each step in the process from the previous step in the process. 25 | --- 26 | speaking: Paulo 27 | text: > 28 | We should be able to conduct a VSM exercise, I suspect it will be an interesting and productive exercise for the team. 29 | --- 30 | speaking: Chun 31 | text: > 32 | Good, but remember we need representatives from all groups with an interest in the process to take part. 33 | --- 34 | speaking: Paulo 35 | text: > 36 | Got it, I will reach out to the upstream and downstream groups to make sure they engage. 37 | --- 38 | speaking: Chun 39 | text: > 40 | Then having come to an agreed understanding of the current process, we as a group need to define what awesome would look like. 41 | --- 42 | speaking: Tina 43 | text: > 44 | Awesome? 45 | --- 46 | speaking: Chun 47 | text: > 48 | Yes, collectively we need to agree what a perfect process looks like. Awesome is our target condition. 49 | --- 50 | speaking: Dan 51 | text: > 52 | And how do we plan on reaching that target? 53 | --- 54 | speaking: Chun 55 | text: > 56 | One bite at a time, or to be precise, via a series of continuous improvement events also known as Kaizen events. DevOps Kaizen events focus on improving customer/client outcomes by making incremental improvements across the entire value stream. 57 | --- 58 | speaking: Paulo 59 | text: > 60 | I know it is a lot to take in, but I am confident with Chun's coaching, with the support of our leadership and your commitment we will transform our operation for the better. 61 | --- 62 | speaking: Paulo 63 | text: > 64 | Before we proceed, to ensure we are on the right path, let's ask [student]. 65 | -------------------------------------------------------------------------------- /online-devops-dojo/leading-change/assets/prereq.sh: -------------------------------------------------------------------------------- 1 | #!/bin/bash 2 | # This Source Code Form is subject to the terms of the Mozilla Public 3 | # License, v. 2.0. If a copy of the MPL was not distributed with this 4 | # file, You can obtain one at https://mozilla.org/MPL/2.0/. 5 | 6 | COLQUESTION="\u001b[36m" 7 | COLRESET="\u001b[m" 8 | COLINFO="\u001b[37m" 9 | 10 | echo -e "${COLINFO}Installing dependencies...${COLRESET}" 11 | 2>/dev/null 1>/dev/null python3 -m pip install pyyaml 12 | 13 | # if learner doesn't enter name, default will be set in dialog.py 14 | echo "Please enter your first name:" 15 | read FIRSTNAME 16 | 17 | echo $FIRSTNAME > /tmp/firstname.txt 18 | 19 | echo -e "${COLINFO}You are all set! Click on 'CONTINUE'.${COLRESET}" 20 | -------------------------------------------------------------------------------- /online-devops-dojo/leading-change/finish.md: -------------------------------------------------------------------------------- 1 | # Conclusion 2 | 3 | Congratulations, you have completed the Leading Change module of the **Online DevOps Dojo**! 4 | 5 | Before moving on to the next module in this course or going back to work please take a few minutes to consider how you and your colleagues can become change agents in your organization. 6 | -------------------------------------------------------------------------------- /online-devops-dojo/leading-change/intro.md: -------------------------------------------------------------------------------- 1 | ## Welcome! 2 | 3 | Welcome to the **Online DevOps Dojo** Leading Change module. 4 | 5 | ## Purpose 6 | 7 | DevOps Transformations like any other transformational activity can be challenging as enacting changes at the scale required can be hard, time-consuming, and require persistence. 8 | 9 | The primary objective of the "Leading Change" module is to help you to understand that a large factor in the success of DevOps transformations is driven by the organization's ability to empower people to lead change at the different levels in the organization. 10 | 11 | While there are challenges in Leading Change in support of DevOps transformations the rewards are quickly evident as the team and the wider organization begin to experience the benefits which accrue from a successful DevOps transformation. 12 | 13 | The secondary objective of the module is to give you an opportunity to virtually participate in a Leading Change real world scenario using Katacoda. 14 | 15 | If you have not completed the Welcome module you must do so before continuing with the Leading Change module. 16 | 17 | By the end of the lesson and lab, you will be able to: 18 | 19 | * Understand the need for change. 20 | 21 | * List the 3 "ways" of DevOps and the role they play in DevOps transformations. 22 | 23 | * Explain the role of DevOps coaches to help the organization adapt DevOps patterns, practices and tools. 24 | 25 | * Describe the significance of empowering team members at all levels of the organization as change agents. 26 | 27 | * Appreciate the importance of allocating both resources and time to allow the change to succeed. 28 | 29 | * Outline the need to establish a safety-first culture, supporting change and experimentation during a DevOps Transformation. 30 | 31 | * Articulate one potential approach to help ensure a successful DevOps Transformation. 32 | -------------------------------------------------------------------------------- /online-devops-dojo/leading-change/step1.md: -------------------------------------------------------------------------------- 1 | **Charlie** the CEO of the Pet Clinic (serial entrepreneur, multi-industry disruptor and philanthropist) has a keen personal interest in his Pet Clinic business. He views the Pet Clinic business as a natural evolution in the commercial arena of his animal activism activities from his student days. Charlie redirects a large portion of the profits from this venture to animal rescue centers in the communities in which the clinics are located. 2 | 3 | Just over a year ago Charlie had some concerns about the long term viability of the Pet Clinic business. He knew changes were needed to better serve a rapidly evolving and dynamic market place, however he felt his team's ability to deliver those changes were being hampered by their development processes, tools and culture. This often resulted in it taking up to 6 months to get a change released to production and releases, when available, that were either buggy or didn't meet the requirements of the business. 4 | 5 | Struggling to square the circle and unsure how to proceed, he came across a talk on DevOps entitled [Why we need DevOps? - by Gene Kim](https://www.youtube.com/watch?v=877OCQA_xzE) online. Charlie was struck by the elegant simplicity of the 3 ways of DevOps. 6 | 7 | * The **First Way** which aims at maximizing throughput of the entire system, as opposed to the throughput of a specific silo of work or department. 8 | 9 | ![The First Way](../../assets/online-devops-dojo/leading-change/first-way.png) 10 | 11 | * The **Second Way** about creating the right to left feedback loops. The goal being to shorten and amplify feedback loops so corrections can be continually made. 12 | 13 | ![The Second Way](../../assets/online-devops-dojo/leading-change/second-way.png) 14 | 15 | * The **Third Way** involves creating a culture that fosters continual experimentation and understanding that repetition and practice are the prerequisites to mastery. 16 | 17 | ![The Third Way](../../assets/online-devops-dojo/leading-change/third-way.png) 18 | 19 | Researching further: 20 | 21 | * Reading **The DevOps Handbook** and **The Phoenix Project** books 22 | 23 | * Studying the [State of DevOps report](https://puppet.com/resources/whitepaper/state-of-devops-report) 24 | 25 | further convinced him about the potential of DevOps and of its applicability in support of his business philosophy. 26 | 27 | _*"Always be prepared to disrupt your business, otherwise a competitor will disrupt it for you".*_ 28 | 29 | This philosophy served him well in his many business interests which include newspapers, online retailing, space exploration and the pet clinics. 30 | 31 |
💡 **TIP**: Adjust the window size vertical scroller to make the welcome module easier to read ◀▶.
32 | -------------------------------------------------------------------------------- /online-devops-dojo/leading-change/step10-answer.md: -------------------------------------------------------------------------------- 1 | The correct answer is **Conduct a VSM exercise, Create Improvement Themes and 2 | Run DevOps Kaizen Events** 3 | 4 | The recommended sequence of events in a DevOps Transformation is to Conduct VSM 5 | exercise, Create Improvement Themes and Run DevOps Kaizen Events. 6 | -------------------------------------------------------------------------------- /online-devops-dojo/leading-change/step10.md: -------------------------------------------------------------------------------- 1 | **Learner** 2 | 3 | >> Which of the following is the recommended sequence of events in a DevOps Transformation? << 4 | (*) Conduct a VSM exercise, Create Improvement Themes and Run DevOps Kaizen Events. 5 | ( ) Create Improvement Themes, Conduct a VSM exercise and Run DevOps Kaizen Events. 6 | ( ) Conduct DevOps Kaizen Event, Create Improvement Themes and Run VSM exercises. 7 | ( ) All of the above, as culture eats transformation for lunch -------------------------------------------------------------------------------- /online-devops-dojo/leading-change/step11.md: -------------------------------------------------------------------------------- 1 | 2 | With Chun's coaching and Paulo's guidance, and the engagement and support of the executive team, the group decided to start focusing on the following areas: 3 | 4 | * Version Control 5 | 6 | * Continuous Integration 7 | 8 | * Shift Left on Security 9 | 10 | There are dedicated modules in the **Online DevOps Dojo** which cover each of these topics in detail. The modules cover the topics in the context of the journey which the Pet Clinic team undertook as part of their DevOps Transformation. 11 | 12 | Our hope is that you will find the modules useful and enjoyable, and that they will help you to empower yourself as change agent within your own team. 13 | -------------------------------------------------------------------------------- /online-devops-dojo/leading-change/step12-answer.md: -------------------------------------------------------------------------------- 1 | The correct answer is of course **All of the above** 2 | 3 | Your commitment to being a change agent is evident from you making the time to 4 | fit this course into your busy schedule. 5 | 6 | Thank you for that, by way of reward grab a slice of virtual slice of 🍕 and 7 | give your self a virtual round of 👏. 8 | -------------------------------------------------------------------------------- /online-devops-dojo/leading-change/step12.md: -------------------------------------------------------------------------------- 1 | **Learner** 2 | 3 | >> Are you prepared to be a change agent in your organization? << 4 | ( ) Yes, change agents are essential to our success 5 | ( ) I am already a change agent, and ready to do more. 6 | (*) All of the above 7 | -------------------------------------------------------------------------------- /online-devops-dojo/leading-change/step3.md: -------------------------------------------------------------------------------- 1 | 2 | We see the initial transformation being comprised of the following major 3 | elements cultural, process & tooling. 4 | 5 | Given the strategic importance of the Pet Clinic application to the business, 6 | Charlie has asked them to focus on the development process for that application 7 | initially. 8 | 9 | Coincidentally at this time the Pet Clinic application team are battling to 10 | resolve issues encountered by the business following the roll out of a major 11 | upgrade to the application. 12 | 13 | _Note: you will learn more about that situation in the Value Stream Mapping 14 | module._ 15 | 16 | Chun and Paulo realize that while the Pet Clinic development team are under 17 | pressure, the team are also keenly aware of the need to improve their processes. 18 | With the support of **Brenda** from the business and the agreement of the Pet 19 | Clinic development team they focus on that application first. 20 | -------------------------------------------------------------------------------- /online-devops-dojo/leading-change/step4-verify.sh: -------------------------------------------------------------------------------- 1 | #!/bin/bash 2 | 3 | [ -f /tmp/firstname.txt ] && echo "done" -------------------------------------------------------------------------------- /online-devops-dojo/leading-change/step4.md: -------------------------------------------------------------------------------- 1 | The team have decided to embark on a DevOps Transformation and are committed to 2 | help lead the changes required. 3 | 4 | The remainder of this lab is a series of conversational snippets taken from the 5 | transformation the Pet Clinic team undertook. 6 | 7 | First before you continue, let's get your name: click `./prereq.sh`{{execute}} 8 | -------------------------------------------------------------------------------- /online-devops-dojo/leading-change/step5.md: -------------------------------------------------------------------------------- 1 | Paulo schedules a meeting with the Pet Clinic development team, during which he explains the ask from the leadership team to initiate a DevOps transformation. 2 | 3 | He welcomes Chun and describes the role she is to play to help the team with the DevOps transformation. 4 | 5 | Paulo invites Chun to introduce herself and asks her to share her top Learnings from the previous DevOps Transformations she has worked on with the team. 6 | 7 | Chun explains that she is a coach, change facilitator and technologist, that she has been helping organizations make the transition from traditional development practices to DevOps practices and culture. She further explains that she is committed to growing the DevOps coaching community in the organizations she works with by leveraging her experience to coach others. 8 | 9 | Chun's shares her top learnings from previous transformation efforts with the team: 10 | 11 | * Culture eats Transformation for Lunch. 12 | 13 | * Tools are [least] important. 14 | 15 | * Leadership support is key. 16 | 17 | * Invest in a Small Enablement group. 18 | 19 | * Choose wisely what is mandated and top-down. 20 | 21 | * Don’t skip the Value Stream Mapping step. 22 | 23 | * Set overall goals/measures. 24 | 25 | * Create Improvement Themes. 26 | 27 | * Continuous Improvement via DevOps Kaizen NOT a Big Bang approach. 28 | 29 | * Focus on a small set of common capabilities / shared services. 30 | 31 | * Develop Champions, Change Agents, Coaches. 32 | 33 | * Start now and never finish. 34 | 35 | The team are excited and challenged by the ask. 36 | 37 | Paulo thanks Chun for the overview and opens the floor to questions. 38 | -------------------------------------------------------------------------------- /online-devops-dojo/leading-change/step6-verify.sh: -------------------------------------------------------------------------------- 1 | #!/bin/bash 2 | 3 | [ -f /tmp/dialog1played.txt ] && echo "done" -------------------------------------------------------------------------------- /online-devops-dojo/leading-change/step6.md: -------------------------------------------------------------------------------- 1 | ![](../../assets/online-devops-dojo/leading-change/team-chat.jpg) 2 | 3 | Click: `./dialog1.sh`{{execute}} 4 | 5 | And follow the dialog in the terminal window... 6 | -------------------------------------------------------------------------------- /online-devops-dojo/leading-change/step7-answer.md: -------------------------------------------------------------------------------- 1 | The correct answer is **None of the above** 2 | 3 | The following are principles which contribute to a successful DevOps Transformation: 4 | 5 | * Continuous Improvement via DevOps Kaizen NOT a Big Bang approach 6 | 7 | * Shouldn't skip the Value Stream Mapping step 8 | 9 | * Culture eats Transformation for Lunch, Tools are [least] important 10 | -------------------------------------------------------------------------------- /online-devops-dojo/leading-change/step7.md: -------------------------------------------------------------------------------- 1 | **Learner** 2 | 3 | >> Which of the following principles contribute to successful DevOps Transformations? << 4 | ( ) Improvement via a Big Bang approach NOT DevOps Kaizen events. 5 | ( ) OK, to skip the Value Stream Mapping step. 6 | ( ) Tools over culture is key. 7 | (*) None of the above -------------------------------------------------------------------------------- /online-devops-dojo/leading-change/step8.md: -------------------------------------------------------------------------------- 1 | Before embarking on the DevOps transformation Chun works with the team to create their DevOps Manifesto. 2 | 3 | The Pet Clinic development team's DevOps Manifesto is comprised of a set of foundational values and supporting principles. 4 | 5 | The manifesto outlines how DevOps will be used by the team in support of the incremental development and rapid delivery of high-quality working software to their customers in the business. 6 | 7 | **Pet Clinic Development Team's DevOps Manifesto** 8 | 9 | * **Optimized**: We optimize end to end. No local-only optimization. 10 | 11 | * **Inner Source**: All of our code is Inner Source. Our work is visible. 12 | 13 | * **Scientific**: We formulate hypotheses; validate them with experience and data, continuously testing. 14 | 15 | * **APIs**: Resources are controlled by APIs. Everything as code (version control, peer reviewed, automatically tested). 16 | 17 | * **Pipelines**: All our changes go through our continuous delivery pipelines: application, compute, storage, DB, network, OS. No alternative. 18 | 19 | * **Teams**: Integrated, empowered, self organizing teams. 20 | 21 | * **Trust**: We value trust and responsibility. But we verify – through the CI/CD pipeline. 22 | 23 | Based on the manifesto the team agree to prioritize the following activities: 24 | 25 | * Source Code Management 26 | 27 | * CI/CD Pipeline 28 | 29 | * Test Automation 30 | 31 | * Documentation as code 32 | 33 | * Infrastructure as code 34 | 35 | * Safety Culture 36 | -------------------------------------------------------------------------------- /online-devops-dojo/leading-change/step9-verify.sh: -------------------------------------------------------------------------------- 1 | #!/bin/bash 2 | 3 | [ -f /tmp/dialog2played.txt ] && echo "done" -------------------------------------------------------------------------------- /online-devops-dojo/leading-change/step9.md: -------------------------------------------------------------------------------- 1 | ![](../../assets/online-devops-dojo/leading-change/team-chat.jpg) 2 | 3 | Click: `./dialog2.sh`{{execute}} 4 | 5 | And follow the dialog in the terminal window... 6 | -------------------------------------------------------------------------------- /online-devops-dojo/post-incident-practices/assets/dialog1.sh: -------------------------------------------------------------------------------- 1 | #!/bin/bash 2 | 3 | # clear the screen 4 | clear 5 | 6 | #play the dialog 7 | TERM=xterm-256color python3 dialog.py dialog1.yaml 8 | 9 | echo "Click on 'CONTINUE'." 10 | -------------------------------------------------------------------------------- /online-devops-dojo/post-incident-practices/assets/dialog1.yaml: -------------------------------------------------------------------------------- 1 | --- 2 | speaking: Chun 3 | text: > 4 | Let me start by focusing on what was done well in relation to the incident post-mortem because it is important those practices continue. 5 | --- 6 | speaking: Chun 7 | text: > 8 | The post-mortem was scheduled immediately after the incident was resolved which is as per best practices. 9 | --- 10 | speaking: Santhosh 11 | text: > 12 | What else are we doing well? 13 | --- 14 | speaking: Paulo 15 | text: > 16 | From what we saw, you had all the right people in the meeting. Representatives from the teams who developed, tested, and deployed the application. 17 | --- 18 | speaking: Paulo 19 | text: > 20 | The people who reported the outage, identified the problem, found the root cause of the issue, and the people who resolved the issue. 21 | --- 22 | speaking: Chun 23 | text: > 24 | You created a timeline of the outage and started to get people's perspectives on the events that led to the outage and the outage itself. 25 | --- 26 | speaking: Santhosh 27 | text: > 28 | Good to hear but I think we all know what you are going to say next - at that point it all went off the rails and it degenerated into a finger pointing exercise. 29 | --- 30 | speaking: Paulo 31 | text: > 32 | Exactly. 33 | --- 34 | speaking: Chun 35 | text: > 36 | High performance teams create a Safety Culture where people are empowered to act, expected to act, and rewarded for taking smart action. 37 | --- 38 | speaking: Chun 39 | text: > 40 | Where mistakes are not punished, so that people give open and frank accounts of their actions which may have contributed to the outage. 41 | --- 42 | speaking: Santhosh 43 | text: > 44 | And how does your suggestion for a Safety Culture apply to the post incident post-mortem? 45 | --- 46 | speaking: Chun 47 | text: > 48 | The postmortem should be blameless and be focused on learning as much as possible from an event or outage. It should be used to instill a culture of action in the team. 49 | --- 50 | speaking: Paulo 51 | text: > 52 | OK so how might have the post-mortem we held yesterday played out if it was held as a blameless post-mortem in a Safety Culture? 53 | --- 54 | speaking: Chun 55 | text: > 56 | Interesting question, I will need some volunteers to participate in a little role playing exercise to explain. 57 | --- 58 | speaking: Team 59 | text: > 60 | Groans and starts looking at their feet. 61 | --- 62 | speaking: Chun 63 | text: > 64 | Laughs and tells everyone not to be shy - the exercise will be fun. 65 | --- 66 | speaking: Team 67 | text: > 68 | Of course it will. 69 | --- 70 | speaking: Chun 71 | text: > 72 | First, let's ask some questions to [student]. 73 | -------------------------------------------------------------------------------- /online-devops-dojo/post-incident-practices/assets/dialog2.sh: -------------------------------------------------------------------------------- 1 | #!/bin/bash 2 | 3 | # clear the screen 4 | clear 5 | 6 | #play the dialog 7 | TERM=xterm-256color python3 dialog.py dialog2.yaml 8 | 9 | echo "Click on 'CONTINUE'." 10 | -------------------------------------------------------------------------------- /online-devops-dojo/post-incident-practices/assets/prereq.sh: -------------------------------------------------------------------------------- 1 | #!/bin/bash 2 | # This Source Code Form is subject to the terms of the Mozilla Public 3 | # License, v. 2.0. If a copy of the MPL was not distributed with this 4 | # file, You can obtain one at https://mozilla.org/MPL/2.0/. 5 | 6 | COLQUESTION="\u001b[36m" 7 | COLRESET="\u001b[m" 8 | COLINFO="\u001b[37m" 9 | 10 | echo -e "${COLINFO}Installing dependencies...${COLRESET}" 11 | 2>/dev/null 1>/dev/null python3 -m pip install pyyaml 12 | 13 | # if learner doesn't enter name, default will be set in dialog.py 14 | echo "Please enter your first name:" 15 | read FIRSTNAME 16 | 17 | echo $FIRSTNAME > /tmp/firstname.txt 18 | 19 | echo -e "${COLINFO}You are all set! Click on 'CONTINUE'.${COLRESET}" -------------------------------------------------------------------------------- /online-devops-dojo/post-incident-practices/finish.md: -------------------------------------------------------------------------------- 1 | # Conclusion 2 | 3 | Congratulations, you have completed the Post Incident Practices module of the **Online DevOps Dojo**! 4 | 5 | Before moving on to the next module in this course or going back to work please take a few minutes to consider how you and your colleagues can establish a Safety Culture, conduct blameless post-mortems and create a “code of conduct” to help you better manage incidents in all phases of their life cycle. 6 | -------------------------------------------------------------------------------- /online-devops-dojo/post-incident-practices/intro.md: -------------------------------------------------------------------------------- 1 | ## Welcome! 2 | 3 | Welcome to the **Online DevOps Dojo** Post Incident Practices module. 4 | 5 | ## Purpose 6 | 7 | The primary objective of the "Post Incident Practices" module is to help you leverage DevOps principles to get better at Incident Management. Additionally you will learn how to establish a Safety Culture, conduct blameless post-mortems and create a “code of conduct” to help your team manage incidents in all phases of their life cycle. 8 | 9 | The secondary objective is to give you an opportunity to virtually participate in a Post Incident Practices real world scenario using Katacoda. 10 | 11 | If you have not completed the Welcome module you should do so before continuing with the Post Incident Practices module. 12 | 13 | By the end of the lesson, the learners should be able to 14 | 15 | * List the 5 steps in an incident life cycle. 16 | * Understand the role of DevOps in creating effective post incident practices. 17 | * Explain the importance of focusing on continuous learning. 18 | * Explain the need to continually enact improvements to incident management practices. 19 | * Create a code of conduct to help your team get out of a reactive break/fix cycle. 20 | * Explain the need for and describe how to establish a Safety Culture. 21 | * Conduct blameless post-mortems. 22 | -------------------------------------------------------------------------------- /online-devops-dojo/post-incident-practices/step1.md: -------------------------------------------------------------------------------- 1 | Prior to their DevOps transformation the post incident practices in the Pet Clinic team were reactive, painful, and a constant source of stress for employees. 2 | 3 | A large event or outage would occur. Depending on the severity of the issue there would be a mild organized panic or a mad disorganized panic. The incident would be resolved. Everyone would say there has to be a better way of doing things. The team would make some vague plans to get together and discuss how best to improve things. Life would take over with the normal day to day routine of development, testing, and operations reasserting themselves - until the next large event or outage when the cycle would repeat. 4 | 5 | The Pet Clinic team had the best intentions and the right idea, in that to get better at Incident Management they needed to commit to getting better at Incident Management. However, they lacked the will, resources, and time to get better between events. 6 | 7 | This was not a recipe for success, and had knock-on effects in terms of stakeholder confidence in the team, staff morale, work life balance, and ultimately staff retention. 8 | 9 | Following a another large scale outage, the team members are keen to leverage the opportunity that the DevOps transformation offers to improve their post incident practices at all stages of the incident life cycle. 10 | 11 | The 5 phases in the typical incident life cycle are 12 | 13 | * Detection 14 | * Response 15 | * Remediation 16 | * Analysis 17 | * Readiness/Kaizen 18 | 19 | The team wants to work with **Chun** to create a “code of conduct” aligned with DevOps principles to help them better manage incidents in all phases of the typical incident life cycle. 20 | 21 | The phases for pre and post DevOps transformation incident practices will largely stay the same, what will change is the manner in which the phases are addressed using DevOps culture, processes, and methodologies. 22 | 23 | This is **Post Incident Practices**. 24 | 25 |
💡 **TIP**: Adjust the window size vertical scroller to make the welcome module easier to read ◀▶
26 | -------------------------------------------------------------------------------- /online-devops-dojo/post-incident-practices/step10.md: -------------------------------------------------------------------------------- 1 | Chun also shares some ideas what should be included in the team's post incident practices code of conduct: 2 | 3 | **Code of Conduct** 4 | 5 | |Detection|Response|Remediation|Analysis|Readiness/Kaizen| 6 | |---|---|---|---|---| 7 | |Monitors|Alerts|Tickets|Blameless Post-Mortems|Continuous Improvement| 8 | |Metrics|SLAs|Fixes/Patches|Why?|Continuous Learning | 9 | |Thresholds|Escalations|Releases|Root Cause Analysis| Site Reliability Engineering| 10 | |Triggers|On Call|Deployments|Publish Results|Chaos Monkey/Game Days| 11 | ||Swarm Teams|Pipelines/Infrastructure As Code||Runbooks|| 12 | 13 | A number of these topics are covered in the first stripe of the **Online DevOps Dojo**, others will be covered in subsequent stripes. 14 | -------------------------------------------------------------------------------- /online-devops-dojo/post-incident-practices/step11-answer.md: -------------------------------------------------------------------------------- 1 | The correct answer is **Blameless post-mortems** and **Addressing the multiple systemic contributing factors** are recommended approaches for post incident practices while **Surface Level post incident reviews** and **Seeking Single Root Cause** are not. 2 | -------------------------------------------------------------------------------- /online-devops-dojo/post-incident-practices/step11.md: -------------------------------------------------------------------------------- 1 | **Learner** 2 | 3 | >> Which are recommended approaches for post incident practices? << 4 | [*] Blameless post-mortems 5 | [ ] Surface Level post incident reviews 6 | [*] Addressing the multiple systemic contributing factors 7 | [ ] Seeking Single Root Cause 8 | -------------------------------------------------------------------------------- /online-devops-dojo/post-incident-practices/step2.md: -------------------------------------------------------------------------------- 1 | A production incident has occurred which took the Pet Clinic application offline, thus breaching agreed SLAs with the customers and exposing the company to potential financial penalties. 2 | 3 | The team - **Adam** the Admin/SRE, **Dan** the Developer, and **Tina** the tester have investigated with the assistance of **Brenda** from the business & **Selma** from security. The issue has been resolved, a patch prepared, the patch has been deployed, and the application is back online. 4 | 5 | The team as per their post incident management practices holds an incident post-mortem. 6 | 7 | It is not a pleasant meeting. The questions at hand include how another major upgrade to the system was delivered late, was prone to errors, and suffered from periodic performance issues. 8 | 9 | These are the practitioners. 10 | 11 | | | | 12 | |---|---| 13 | |![Chun](../../assets/online-devops-dojo/post-incident-practices/chun.png)|**Chun** DevOps coach engaged to help the company and development team make the shift to a new way of working by mentoring, empowering, and coaching the team. | 14 | |![Paulo](../../assets/online-devops-dojo/post-incident-practices/paulo.png)|**Paulo** Product Owner appointed to facilitate the change, experienced Agile practitioner with some exposure to DevOps tools and processes. | 15 | |![Santhosh](../../assets/online-devops-dojo/post-incident-practices/santhosh.png)|**Santhosh** Scrum Master participating in post incident practices. | 16 | |![Brenda](../../assets/online-devops-dojo/post-incident-practices/brenda.png)|**Brenda** Business representative participating in post incident practices. | 17 | |![Selma](../../assets/online-devops-dojo/post-incident-practices/selma.png)|**Selma** Security representative participating in post incident practices. | 18 | |![Adam](../../assets/online-devops-dojo/post-incident-practices/adam.png)|**Adam** IT Admin representative participating in post incident practices. | 19 | |![Dan](../../assets/online-devops-dojo/post-incident-practices/dan.png)|**Dan** Development representative participating in post incident practices. | 20 | |![Tina](../../assets/online-devops-dojo/post-incident-practices/tina.png)|**Tina** Test representative participating in post incident practices. | 21 | -------------------------------------------------------------------------------- /online-devops-dojo/post-incident-practices/step3.md: -------------------------------------------------------------------------------- 1 | _Ladies and gentlemen: the story you are about to hear is true. In some places the names have been changed to protect the innocent._ 2 | 3 | **Basil** from the business is not happy, he is explaining to the team that this is not the first event of this nature and outlining the impact to the business. He also outlines the effects issues of this nature are having on his and the team's credibility. 4 | 5 | Responses include: 6 | 7 | **Arkwright** _"Oh that was after the admin team deployed a change **Sybil** from security approved."_ 8 | 9 | **Dougal** _"The development team could have fixed the issues prior to deployment if **Ted** and the testers had told us about them."_ 10 | 11 | **Dougal** and the Developers are blaming **Ted** and the testers. The testers are blaming the developers. **Polly** the product owner is pointing to infrastructure issues caused by **Arkwright** and the admins who in turn are pointing to scheduling issues caused by **Sam** the Scrum master. 12 | 13 | The only thing everyone agrees on is that someone else is more at to blame than they are for the issues encountered. 14 | 15 | The conversation revolves around _who did what_ and _who approved it_ rather than on _why the issue occurred_ and _what in the system can be done to prevent similar issues occurring in the future_. 16 | 17 | The DevOps enablement team **Paulo** and **Chun** are interested observers in the meeting. They arrange a follow up meeting for the next day to share their observations with the team. 18 | 19 | Chun discusses the post-mortem process with the team. She explains the issues she saw with the post-mortem, the primary one being that it was conducted in the wrong manner with a focus on attributing responsibility for the outage rather than focusing on the root cause of the outage. 20 | 21 | Chun further explains that a blameful culture is very harmful as it can cause a myriad of problems including: 22 | 23 | * Staff retention 24 | 25 | * Truth being hidden 26 | 27 | * Culture where no one wants to speak out 28 | 29 | * Leaders not knowing what is really happening 30 | 31 | * Management by fear 32 | 33 | The team admits that their practices might be improved and ask Chun how she thinks they should have conducted the post-mortem. 34 | -------------------------------------------------------------------------------- /online-devops-dojo/post-incident-practices/step4-verify.sh: -------------------------------------------------------------------------------- 1 | #!/bin/bash 2 | 3 | [ -f /tmp/firstname.txt ] && echo "done" -------------------------------------------------------------------------------- /online-devops-dojo/post-incident-practices/step4.md: -------------------------------------------------------------------------------- 1 | 2 | The team have decided to embark on a DevOps Transformation and are committed to improving their post incident practices. 3 | 4 | The remainder of this lab is a series of conversational snippets taken from the transformation of their post incident management practices, which the Pet Clinic team undertook. 5 | 6 | First before you continue, let's get your name: click `./prereq.sh`{{execute}} 7 | -------------------------------------------------------------------------------- /online-devops-dojo/post-incident-practices/step5-verify.sh: -------------------------------------------------------------------------------- 1 | #!/bin/bash 2 | 3 | [ -f /tmp/dialog1played.txt ] && echo "done" -------------------------------------------------------------------------------- /online-devops-dojo/post-incident-practices/step5.md: -------------------------------------------------------------------------------- 1 | ![](../../assets/online-devops-dojo/post-incident-practices/team-chat.jpg) 2 | 3 | Click: `./dialog1.sh`{{execute}} 4 | 5 | and follow the dialog in the terminal window. 6 | -------------------------------------------------------------------------------- /online-devops-dojo/post-incident-practices/step6-answer.md: -------------------------------------------------------------------------------- 1 | The correct answer is **None of the above** 2 | 3 | The attributes listed are all associated with a Safety Culture 4 | 5 | * People give open and frank accounts of their actions which may have contributed an outage. 6 | 7 | * The team feel empowered to act and are recognized for taking smart action. 8 | 9 | * Leaders are more informed re what is actually going on. 10 | -------------------------------------------------------------------------------- /online-devops-dojo/post-incident-practices/step6.md: -------------------------------------------------------------------------------- 1 | **Learner** 2 | 3 | >> Which of the following are likely to occur in a blameful culture? << 4 | ( ) People give open and frank accounts of their actions which may have contributed an outage. 5 | ( ) The team feel empowered to act and are recognized for taking smart action. 6 | ( ) Leaders are more informed re what is actually going on. 7 | (*) None of the above 8 | -------------------------------------------------------------------------------- /online-devops-dojo/post-incident-practices/step7-verify.sh: -------------------------------------------------------------------------------- 1 | #!/bin/bash 2 | 3 | [ -f /tmp/dialog2played.txt ] && echo "done" -------------------------------------------------------------------------------- /online-devops-dojo/post-incident-practices/step7.md: -------------------------------------------------------------------------------- 1 | ![](../../assets/online-devops-dojo/post-incident-practices/team-chat.jpg) 2 | 3 | The blameless port-mortem role playing exercise begins. 4 | 5 | Click: `./dialog2.sh`{{execute}} 6 | 7 | and follow the dialog in the terminal window. 8 | -------------------------------------------------------------------------------- /online-devops-dojo/post-incident-practices/step8.md: -------------------------------------------------------------------------------- 1 | Chun shares best practices on how to conduct a blameless post-mortem and details on a key metric the team should focus on in terms of post incident practices. 2 | 3 | **Post Incident Practices** 4 | 5 | | From || To | 6 | | --- | --- |--- | 7 | | Seeking Single Root Cause for an outage | ➡ | Addressing the multiple systemic contributing factors to an outage | 8 | | Prevention (only) | ➡ | Breaking down TTR (time to resolve components) | 9 | | Blameful post-mortems | ➡ | Blameless post-mortems | 10 | | Surface Level post incident reviews | ➡ | Strategic Level understanding and improvement | 11 | 12 | **Mean Time to Recover (MTTR) Metric** 13 | 14 | The key metric for Post Incident Practices is Mean Time to Recover (MTTR). MTTR captures the mean (average) time it takes to recover from a production issue. 15 | 16 | Typically the metric is an average of the production downtime calculated across the last ten downtimes. 17 | 18 | The hope and expectation is that MTTR will trend lower as DevOps maturity grows and incident practices improve by using the following process: 19 | 20 | * Measure 21 | 22 | `MTTR = MTTD (Detect) + MTTI (Isolate) + MTTF (Fix)` 23 | 24 | * Determine top contributing factors for preventing, detecting, isolating, and fixing issues. 25 | 26 | * Add remediation steps to prioritized team backlog. 27 | -------------------------------------------------------------------------------- /online-devops-dojo/post-incident-practices/step9-answer.md: -------------------------------------------------------------------------------- 1 | The correct calculation for MTTR is: 2 | 3 | **MTTR = MTTD (Detect) + MTTI(Isolate) + MTTF(Fix)** 4 | -------------------------------------------------------------------------------- /online-devops-dojo/post-incident-practices/step9.md: -------------------------------------------------------------------------------- 1 | **Learner** 2 | 3 | >> Which of the following options shows the correct calculation for MTTR? << 4 | (*) MTTR = MTTD (Detect) + MTTI (Isolate) + MTTF (Fix) 5 | ( ) MTTR = MTTD (Detect) * MTTI (Isolate) * MTTF (Fix) 6 | ( ) MTTR = (MTTD (Detect) + MTTI (Isolate)) - MTTF (Fix) 7 | ( ) MTTR = MTTD (Detect) - (MTTI (Isolate) + MTTF (Fix)) 8 | -------------------------------------------------------------------------------- /online-devops-dojo/shift-security-left/assets/index.html: -------------------------------------------------------------------------------- 1 | 2 |
3 | 4 | 5 | 6 | 26 |
27 | 28 | 29 |
30 |

pom.xml file

31 |
32 |

pom.xml file in master branch

33 | github_url/blob/master/pom.xml 34 |
35 |
36 |

pom.xml file in deps-check branch

37 | github_url/blob/deps-check/pom.xml 38 |
39 |

Jenkinsfile

40 |
41 |

Jenkinsfile file

42 | github_url/blob/deps-check/Jenkinsfile 44 |
45 |
46 | 47 | 48 | -------------------------------------------------------------------------------- /online-devops-dojo/shift-security-left/assets/reset.sh: -------------------------------------------------------------------------------- 1 | # 2 | # Reset GitHub repository back to the first commit 3 | # 4 | # This Source Code Form is subject to the terms of the Mozilla Public 5 | # License, v. 2.0. If a copy of the MPL was not distributed with this 6 | # file, You can obtain one at https://mozilla.org/MPL/2.0/. 7 | 8 | if [ -f /tmp/jenkins_ready ]; then 9 | # We have user's ID and PAT 10 | git config --global push.default simple 11 | cd ~/pet-clinic && git rev-list --max-parents=0 HEAD | xargs git reset --hard && git push --force 12 | git pull 13 | cd - 14 | else 15 | echo "Please execute the prepare.sh script before" 16 | fi -------------------------------------------------------------------------------- /online-devops-dojo/shift-security-left/finish.md: -------------------------------------------------------------------------------- 1 | # Conclusion 2 | 3 | Congratulations, you have completed the Shift Security Left module of the 4 | **Online DevOps Dojo**! 5 | 6 | Would you like to build yourself new training scenarios, enhance the existing 7 | or just provide feedback and suggestions? Then you are welcome to fork the 8 | [Online DevOps Dojo](https://github.com/dxc-technology/about-devops-dojo) repository 9 | and start from there. 10 | -------------------------------------------------------------------------------- /online-devops-dojo/shift-security-left/index.json: -------------------------------------------------------------------------------- 1 | { 2 | "pathwayTitle": "Online DevOps Dojo", 3 | "title": "Shift Left on Security", 4 | "private": true, 5 | "description": "Security must be considered from the beginning and continuously assessed.", 6 | "difficulty": "intermediate", 7 | "time": "45 minutes", 8 | "details": { 9 | "steps": [ 10 | { 11 | "title": "Introduction", 12 | "text": "step1.md" 13 | }, 14 | { 15 | "title": "Setup", 16 | "text": "step2.md", 17 | "verify": "step2-verify.sh" 18 | }, 19 | { 20 | "title": "Setup (continued)", 21 | "text": "step3.md" 22 | }, 23 | { 24 | "title": "Team's dialog", 25 | "text": "step4.md" 26 | }, 27 | { 28 | "title": "Adding a dependency scanner", 29 | "text": "step5-nospell.md" 30 | }, 31 | { 32 | "title": "Add scanner in the pipeline", 33 | "text": "step6-nospell.md" 34 | }, 35 | { 36 | "title": "Fixing the vulnerability", 37 | "text": "step7.md" 38 | }, 39 | { 40 | "title": "Continuous checking", 41 | "text": "step8-nospell.md" 42 | } 43 | ], 44 | "intro": { 45 | "text": "intro.md" 46 | }, 47 | "assets": { 48 | "host01": [ 49 | { "file": "prepare.sh", "target": "~/","chmod": "+x" }, 50 | { "file": "reset.sh", "target": "~/","chmod": "+x" }, 51 | { "file": "index.html", "target": "~/nginx"} 52 | ] 53 | }, 54 | "finish": { 55 | "text": "finish.md" 56 | } 57 | }, 58 | "environment": { 59 | "hideintro": false, 60 | "uilayout": "terminal-iframe", 61 | "showdashboard": true, 62 | "dashboards": [ 63 | { "name": "GitHub", "port": 9876}, 64 | { "name": "Pet Clinic", "port": 9966} 65 | ], 66 | "uimessage1": "\u001b[32mYour Interactive Bash Terminal.\r\nYou can type in and run shell commands here.\r\n\u001b[m" 67 | }, 68 | "backend": { 69 | "imageid": "devopsdojo-ubuntu-yb" 70 | } 71 | } 72 | -------------------------------------------------------------------------------- /online-devops-dojo/shift-security-left/intro.md: -------------------------------------------------------------------------------- 1 | ## Welcome! 2 | 3 | Welcome to the **Online DevOps Dojo** module on shifting security left. 4 | If you have not completed the Welcome module you must do so before continuing 5 | with this module. 6 | 7 | ## Purpose 8 | 9 | The primary objective of the "Shift Left on Security" module is to help you to 10 | understand the principles and benefits of Shifting Left on Security and enable 11 | you and your team to Shift Left on Security in your daily work. 12 | 13 | The secondary objective is to give you an opportunity to complete a Shift Left 14 | on Security real world scenario using Katacoda in **your** Sandbox environment. 15 | 16 | Remember the Sandbox is your personal clone of the Pet Clinic Repository. The 17 | Sandbox is the one which you created in the Welcome module. You are free to 18 | experiment in your Sandbox without fear of impacting the lab or other learners. 19 | 20 | By the end of the lesson, you should be able to: 21 | 22 | * articulate the need to Shift Left on Security, 23 | * integrate Security Testing in the daily work of the Scrum team as part of a 24 | CI/CD pipeline, 25 | * describe how to reduce surface areas of risk and enforce consistency in the 26 | the application of security testing, 27 | * understand the need to provide traceability of production artifacts, 28 | * explain the importance of using commercially available and/or open source 29 | tools which the security team have reviewed and tools rather than custom 30 | solutions for security testing. 31 | 32 | ## Definition 33 | 34 | 🤷🏼‍♀️ 6 mentions of *shift left* already... what does this mean? 35 | 36 | Usually a Continuous Integration pipeline is represented by several stages 37 | starting from left to right. Hopefully you already have security checks a some 38 | point. Shifting left means to run these security checks as early as possible. 39 | Fail fast and do not waste time to pass other stages if you can detect earlier 40 | that you have to rework your code. 41 | -------------------------------------------------------------------------------- /online-devops-dojo/shift-security-left/step1.md: -------------------------------------------------------------------------------- 1 | ![Newspaper](../../assets/online-devops-dojo/shift-security-left/newspaper.jpg) 2 | 3 | We join our intrepid crew in the midst of a fire drill, red light floods the teams co-located office space in a digital hub, sirens can be heard in the background, together with a robotic voice regularly repeating "**We have been hacked, this is not a drill ...**". 4 | 5 | ![Hal](../../assets/online-devops-dojo/shift-security-left/hal.png) 6 | 7 | A security breach, specifically a [SQL (pronounced "see-kwuhll") Injection Vulnerability](https://en.wikipedia.org/wiki/SQL_injection), has been identified following Hal the hacker's activities. 8 | 9 | A SQL Injection vulnerability gives a hacker the ability to compromise the SQL queries that an application sends to it's back-end database. This is one of the most serious vulnerabilities that a business can face because it can result in a hacker getting access to the sensitive information stored in the application's database such as usernames, passwords, names, contact details, and even credit card details. 10 | 11 | ![Brenda](../../assets/online-devops-dojo/shift-security-left/brenda.png) 12 | 13 | > We need to fix the immediate vulnerability, and also put a process in place to prevent a repeat hack is to be the teams number 1 priority for the forthcoming sprint. Look, we are even in the local news! 14 | 15 | ![Adam](../../assets/online-devops-dojo/shift-security-left/adam.png) 16 | 17 | > Yes, we have investigated the issue and created stories in the backlog with detailed acceptance criteria to enable the planned Shift Left on Security. 18 | 19 | ![Selma](../../assets/online-devops-dojo/shift-security-left/selma.png) 20 | 21 | > We have created stories that encompass Static Application Security Testing (SAST) and Dynamic Application Security Testing (DAST). SAST involves testing of the source code, binary or byte code of an application. It doesn't need a running system. DAST involves testing an application while it is running. DAST doesn't require access to the source code or the binaries. 22 | 23 | ![Paulo](../../assets/online-devops-dojo/shift-security-left/paulo.png) 24 | 25 | > We have formed a [Swarm team](https://www.infoq.com/news/2013/02/swarming-agile-teams-deliver) to work the stories. We have a small team of domain experts, Adam (SRE), Dan (Developer), Selma (Security), and Tina (Tester) gathered together for a short period to solve a problem or deliver some key functionality as expeditiously as possible. 26 | 27 | ![Santhosh](../../assets/online-devops-dojo/shift-security-left/santhosh.png) 28 | 29 | > This is a high visibility issue so - acting as the servant leader - I will have a key role to protect the team from all the 'noise' around the hack to better enable them to focus on the problem at hand. 30 | 31 | This is **Shift Left on Security**. 32 | -------------------------------------------------------------------------------- /online-devops-dojo/shift-security-left/step2-verify.sh: -------------------------------------------------------------------------------- 1 | #!/bin/bash 2 | 3 | [ -f /tmp/jenkins_ready ] && echo "done" -------------------------------------------------------------------------------- /online-devops-dojo/shift-security-left/step2.md: -------------------------------------------------------------------------------- 1 | To proceed with this lab you need to have your own copy of the Pet Clinic GitHub repository under your GitHub user name. If you have not done so please take the Welcome module. 2 | 3 | Then run the following command to bring up Jenkins and connect it to your copy of the Pet Clinic application's code. This script may take a few minutes to run. 4 | 5 | **Note**: you will re-use GitHub's "Personal Access Token" you have created in the Welcome module. If you need to generate a new one, go to [https://github.com/settings/tokens](https://github.com/settings/tokens) and save it for later. 6 | 7 | Let's go ahead and prepare our environment, click this: 8 | 9 | `./prepare.sh`{{execute}} 10 | 11 | answer the question and wait for the "Click on 'CONTINUE'" message. 12 | 13 |
14 | 💣Workspace reset instructions 15 | If you want to reset your Pet Clinic repository to its original state, run this command:
16 | `./reset.sh`{{execute}}
17 |
18 | 🛑✋ The GitHub repository will be back to the state from after the Welcome module. 19 |
20 | -------------------------------------------------------------------------------- /online-devops-dojo/shift-security-left/step3.md: -------------------------------------------------------------------------------- 1 | * Now that Jenkins is ready, open the Jenkins admin dashboard: 2 | https://[[HOST_SUBDOMAIN]]-8080-[[KATACODA_HOST]].environments.katacoda.com/ 3 | * Authenticate with the user `admin`{{copy}}, password 4 | `569747beeffb19d5cad165c7907b6471`{{copy}} 5 | 6 | 💡 **TIP**: 🦊 Firefox user? Use CTRL+INS / 7 | SHIFT+INS to copy/paste your Personal Access Token in the 8 | window. 9 | -------------------------------------------------------------------------------- /online-devops-dojo/shift-security-left/step4.md: -------------------------------------------------------------------------------- 1 | ⏳📅 A week has passed... 2 | 3 | ![Selma](../../assets/online-devops-dojo/shift-security-left/selma.png) 4 | 5 | > Now that the fire drill is over, we need to take advantage of this incident (some call it an "unplanned investment opportunity") to invest and include security early in our cycle. 6 | > Between Static Application Security Testing (SAST) and Dynamic Application Security Testing (DAST), I suggest we start with SAST and include this activity in our Continuous Integration pipeline. 7 | 8 | ![Tina](../../assets/online-devops-dojo/shift-security-left/tina.png) 9 | 10 | > One of my concerns is all the dependencies our code relies on. Not that we can nor want to get rid of them, but we need to get this under control. Vulnerabilities are found everyday. Checking that our dependencies don't become vulnerable over time is going to be key to protect the personal data of our customers. 11 | 12 | ![Chun](../../assets/online-devops-dojo/shift-security-left/chun.png) 13 | 14 | > The Continuous Integration Pipeline is the perfect place to add quality gates such as SAST. There are many tools we can use - including Open Source ones - such as the [OWASP dependency check](https://owasp.org/www-project-dependency-check/). 15 | > We want this gate to run not only when we introduce changes in the code, but also on a regular basis - for example daily. This way, when (**not if**) a vulnerability is discovered in one of our dependency, our CI pipeline will detect it and notify us so that we can take action. 16 | 17 | ![Selma](../../assets/online-devops-dojo/shift-security-left/selma.png) 18 | 19 | > I know OWASP (Open Web Application Security Project)! This is a not-for-profit charitable organization, and it can be trusted. Including this dependency checker in the pipeline is a great idea! I will sleep better at night 💤🌛 knowing that we are reducing our attack surface on that front by including security in our CI pipeline, in other words by shifting security left towards the original cause of the vulnerability. 20 | -------------------------------------------------------------------------------- /online-devops-dojo/shift-security-left/step5-nospell.md: -------------------------------------------------------------------------------- 1 | ![Dan](../../assets/online-devops-dojo/shift-security-left/dan.png) 2 | 3 | > As Pet Clinic is a Java project, we can easily add the [OWASP dependency check](https://owasp.org/www-project-dependency-check/) as part of our pipeline, in our `pom.xml` file, as a Maven plugin. Let's do this! 4 | 5 | ## Steps 6 | 7 | * Navigate to your GitHub copy of the Pet Clinic application to find [`pom.xml`](https://[[HOST_SUBDOMAIN]]-9876-[[KATACODA_HOST]].environments.katacoda.com/#pomfile) in the master branch. 8 | * Click on the pencil icon in the top right corner to edit the file. 9 | * Add the OWASP dependency checker as one of the plugins, around line 306 (after `` without s): 10 | 11 | 
12 |              <plugin>
13 |                 <groupId>org.owasp</groupId>
14 |                 <artifactId>dependency-check-maven</artifactId>
15 |                 <version>6.2.2</version>
16 |                 <configuration>
17 |                     <format>ALL</format>
18 |                     <failBuildOnCVSS>7</failBuildOnCVSS>
19 |                     <cveValidForHours>168</cveValidForHours>
20 |                 </configuration>
21 |                 <executions>
22 |                     <execution>
23 |                         <goals>
24 |                             <goal>check</goal>
25 |                         </goals>
26 |                     </execution>
27 |                 </executions>
28 |             </plugin>
29 |
30 | 31 | * 💡 Note that we fail the build if CVSS is >= 7. It all depends of the context 32 | of your project and where you want to put the bar. More information on CVSS at 33 | [https://www.first.org/cvss/v3.1/user-guide](https://www.first.org/cvss/v3.1/user-guide). 34 | * Create a pull request by committing the changes in a new branch which you will 35 | name: `deps-check`{{copy}} 36 | * The build will trigger automatically. 37 | * Navigate to Jenkins to see the results of the build. 38 | * Be patient. The build will succeed: at this time, we are missing the step in the pipeline 39 | (Jenkinsfile) to actually check for dependencies. The plugin is in the 40 | `pom.xml` file but is not used yet. 41 | -------------------------------------------------------------------------------- /online-devops-dojo/shift-security-left/step6-nospell.md: -------------------------------------------------------------------------------- 1 | ![Dan](../../assets/online-devops-dojo/shift-security-left/dan.png) 2 | 3 | > Now, we need to update the `Jenkinsfile` which describes our Continuous Integration pipeline to add the dependency vulnerability scanner. Initially, I don't want to fail the build because of vulnerabilities in our dependencies. We want to stop the leak and be informed instead. I will mark the build as "unstable" if we have a vulnerability. 4 | > Also, I am gathering a report for the vulnerabilities so that we can analyze it. 5 | 6 | ## Steps 7 | 8 | * Navigate to your copy of the Pet Clinic application to find 9 | [`Jenkinsfile`](https://[[HOST_SUBDOMAIN]]-9876-[[KATACODA_HOST]].environments.katacoda.com/#jenkinsfile), 10 | in the same `deps-check` branch from the pull request. 11 | * Click on the pencil icon in the top right corner to edit the file. 12 | * Add the following stage just above Build stage: 13 | 
14 | 
15 |             stage('Dependency check') {
16 |                 steps {
17 |                     sh "mvn --batch-mode dependency-check:check"
18 |                 }
19 |                 post {
20 |                     always {
21 |                         publishHTML(target:[
22 |                             allowMissing: true,
23 |                             alwaysLinkToLastBuild: true,
24 |                             keepAll: true,
25 |                             reportDir: 'target',
26 |                             reportFiles: 'dependency-check-report.html',
27 |                             reportName: "OWASP Dependency Check Report"
28 |                         ])
29 |                     }
30 |                 }
31 |             }
32 | 
33 |
34 | * Commit in `deps-check` branch. 35 | * The pipeline will trigger automatically. 36 | * Navigate to Jenkins 37 | to see the results. The pipeline will be marked "failed": read the logs of the stage 38 | "Dependency check", then click on Artifacts tab on the top right to see the OWASP report. 39 | 40 | ![OWASP report](../../assets/online-devops-dojo/shift-security-left/owasp-report2.png) 41 |
Blue Ocean view
42 | * You may also switch to Jenkins' classic view. Click on "Go to classic" 43 | ![Go to classic](../../assets/online-devops-dojo/shift-security-left/jenkins-back-to-classic-icon.png) 44 | logo in the upper right corner. Select the "pet-clinic" pipeline, choose "Pull 45 | Requests" and select the latest build from the Build History along the left 46 | side to get to a Jenkins view that matches the below images. 47 | The build will be marked "failed". Read the logs of the stage "Dependency 48 | check" and the OWASP report to see what the issue is. 49 | 50 | ![OWASP report](../../assets/online-devops-dojo/shift-security-left/owasp-report.png) 51 |
Classic view
52 | -------------------------------------------------------------------------------- /online-devops-dojo/shift-security-left/step8-nospell.md: -------------------------------------------------------------------------------- 1 | ![Hal](../../assets/online-devops-dojo/shift-security-left/hal.png) 2 | 3 | > Dang! You make my job really hard now! That's OK though, I continuously monitor for new vulnerabilities. 4 | > This is a waiting game at this point. 5 | 6 | ![Selma](../../assets/online-devops-dojo/shift-security-left/selma.png) 7 | 8 | > Now that we have our dependency scanner in place, how can we continuously scan for new vulnerabilities to defeat the hackers? 9 | 10 | ![Dan](../../assets/online-devops-dojo/shift-security-left/dan.png) 11 | 12 | > The pipeline is perfect for that. Let's update the `Jenkinsfile` to trigger daily, even if there are no new code changes. 13 | 14 | ## Steps 15 | 16 | * Navigate to your copy of the Pet Clinic application to find 17 | [`Jenkinsfile`](https://[[HOST_SUBDOMAIN]]-9876-[[KATACODA_HOST]].environments.katacoda.com/#jenkinsfile), 18 | in the same `deps-check` branch from the pull request. 19 | * Click on the pencil icon in the top right corner to edit the file. 20 | * Below `agent any` in the `Jenkinsfile`, add a scheduled trigger: 21 | 22 | 
23 |     // Scan will run everyday on master
24 |     triggers { cron( (BRANCH_NAME == "master") ? "@daily" : "" ) }
25 |
26 | 27 | * Commit the change in this `deps-check` branch, in the context of the pull request. 28 | * The build will trigger automatically. 29 | * Navigate to Jenkins to see the results of the build. 30 | * The build should still succeed. In addition, it is also now scheduled for daily execution and on master branch only: such schedule would not make sense on development branches which could be many. 31 | * Everything looks good: merge the pull request. 32 | -------------------------------------------------------------------------------- /online-devops-dojo/value-stream-mapping/assets/dialog1.sh: -------------------------------------------------------------------------------- 1 | #!/bin/bash 2 | 3 | # clear the screen 4 | clear 5 | 6 | #play the dialog 7 | TERM=xterm-256color python3 dialog.py dialog1.yaml 8 | 9 | echo "Click on 'CONTINUE'." 10 | -------------------------------------------------------------------------------- /online-devops-dojo/value-stream-mapping/assets/dialog1.yaml: -------------------------------------------------------------------------------- 1 | --- 2 | speaking: Brenda 3 | text: > 4 | VSM sounds interesting what exactly is it? 5 | --- 6 | speaking: Chun 7 | text: > 8 | A Value Stream describes the process used to create and deliver goods, services, solutions and in our case, software. While a Value Stream Map is a pictorial representation of a value stream. 9 | --- 10 | speaking: Santhosh 11 | text: > 12 | A VSM will enable us to see the end to end flow of software from idea to delivery including branches, feedback loops and queues in our process. 13 | --- 14 | speaking: Dan 15 | text: > 16 | We already understand our process why do we need to draw it? We already work as fast as we can, this just seems to be a distraction from writing code. 17 | --- 18 | speaking: Paulo 19 | text: > 20 | I agree we all understand the general process as it applies to our functional areas and our interactions with our direct upstream and downstream activities but I think we don't have a shared understanding of the complete end to end flow. 21 | --- 22 | speaking: Paulo 23 | text: > 24 | The understanding I am referring to would include the nature of handoffs between functions, the lead times, the activity times and the quality of work reaching each of us. I think that lack of understanding is contributing to the problems we have been experiencing. 25 | --- 26 | speaking: Santhosh 27 | text: > 28 | Maybe another way to look at this is to agree what contributes to the time it takes for a feature to be delivered? 29 | --- 30 | speaking: Chun 31 | text: > 32 | Exactly, basically for a work item the Total Duration = Processing Time (Actual Time spent working ) + Waste Time (Handoffs etc.) 33 | --- 34 | speaking: Chun 35 | text: > 36 | A VSM is a pictorial representation, using a standard set of symbols, of an end to end process including lead and activity times for all steps in the process. 37 | --- 38 | speaking: Dan 39 | text: > 40 | OK I think I am starting to understand where you are going with this, what do we do with the VSM once we create it? 41 | --- 42 | speaking: Paulo 43 | text: > 44 | We use it to identify and eliminate waste, waste is any non value add activities in the value stream including handoffs, rework, manual activities, wait times etc. 45 | --- 46 | speaking: Brenda 47 | text: > 48 | We need to do that yesterday, how do we begin? 49 | --- 50 | speaking: Brenda 51 | text: > 52 | First, let's ask some questions to [student]. 53 | -------------------------------------------------------------------------------- /online-devops-dojo/value-stream-mapping/assets/dialog2.sh: -------------------------------------------------------------------------------- 1 | #!/bin/bash 2 | 3 | # clear the screen 4 | clear 5 | 6 | #play the dialog 7 | TERM=xterm-256color python3 dialog.py dialog2.yaml 8 | 9 | echo "Click on 'CONTINUE'." 10 | -------------------------------------------------------------------------------- /online-devops-dojo/value-stream-mapping/assets/dialog2.yaml: -------------------------------------------------------------------------------- 1 | --- 2 | speaking: Tina 3 | text: > 4 | OK we now have the Value Stream mapped, what do we do next? 5 | --- 6 | speaking: Chun 7 | text: > 8 | We need to look at what the VSM is telling us and determine where we need to focus our efforts. 9 | --- 10 | speaking: Selma 11 | text: > 12 | How do we do that? 13 | --- 14 | speaking: Chun 15 | text: > 16 | We need to look for and eliminate non value add activities in the current state VSM. For example: 17 | --- 18 | speaking: Chun 19 | text: > 20 | - How do we significantly increase the percent complete and accurate (%C/A) for each activity? 21 | --- 22 | speaking: Chun 23 | text: > 24 | - How can we improve the processing time (PT) for each activity? 25 | --- 26 | speaking: Chun 27 | text: > 28 | - How do we reduce, or even eliminate the non-productive time in the lead time (LT) for each activity? 29 | --- 30 | speaking: Paulo 31 | text: > 32 | Additional questions to be considered include - 33 | --- 34 | speaking: Paulo 35 | text: > 36 | - What are the boundaries between the activities and why do they exist? 37 | --- 38 | speaking: Paulo 39 | text: > 40 | - What contributes to the LT for each activity including handoffs, queues, and organizational rules & procedures? 41 | --- 42 | speaking: Paulo 43 | text: > 44 | - Who performs each activity, including their roles? 45 | --- 46 | speaking: Paulo 47 | text: > 48 | - What tools are used by people performing each activity? 49 | --- 50 | speaking: Paulo 51 | text: > 52 | - Are there opportunities for automation and/or integration to help improve efficiency of the activities? 53 | --- 54 | speaking: Paulo 55 | text: > 56 | Chun anything you would like to add to that list? 57 | --- 58 | speaking: Chun 59 | text: > 60 | Just a couple. 61 | --- 62 | speaking: Chun 63 | text: > 64 | How can we shift activities left to provide faster feedback? 65 | --- 66 | speaking: Chun 67 | text: > 68 | What other DevOps principles, practices or tools could be applied to improve the end-to-end LT? 69 | --- 70 | speaking: Adam 71 | text: > 72 | Better put on some more coffee and order more pizza, because I for one am keen to start looking for improvements. 73 | --- 74 | speaking: Santhosh 75 | text: > 76 | Consider it done. A word of caution for us as a team, we need to be aware that the debate that leads to answers to those questions can result in a new desired state VSM. 77 | --- 78 | speaking: Chun 79 | text: > 80 | The desired state VSM may have more challenging targets for each of the three key metrics - %C/A, LT, and PT per activity. These targets may need to be implemented over a couple of sprints. 81 | -------------------------------------------------------------------------------- /online-devops-dojo/value-stream-mapping/assets/prereq.sh: -------------------------------------------------------------------------------- 1 | #!/bin/bash 2 | # This Source Code Form is subject to the terms of the Mozilla Public 3 | # License, v. 2.0. If a copy of the MPL was not distributed with this 4 | # file, You can obtain one at https://mozilla.org/MPL/2.0/. 5 | 6 | COLQUESTION="\u001b[36m" 7 | COLRESET="\u001b[m" 8 | COLINFO="\u001b[37m" 9 | 10 | echo -e "${COLINFO}Installing dependencies...${COLRESET}" 11 | 2>/dev/null 1>/dev/null python3 -m pip install pyyaml 12 | 13 | # if learner doesn't enter name, default will be set in dialog.py 14 | echo "Please enter your first name:" 15 | read FIRSTNAME 16 | 17 | echo $FIRSTNAME > /tmp/firstname.txt 18 | 19 | echo -e "${COLINFO}You are all set! Click on 'CONTINUE'.${COLRESET}" -------------------------------------------------------------------------------- /online-devops-dojo/value-stream-mapping/finish.md: -------------------------------------------------------------------------------- 1 | # Conclusion 2 | 3 | Congratulations, you have completed the Value Stream Mapping module of the **Online DevOps Dojo**! 4 | 5 | Before moving on to the next module in this course or going back to work please take a few minutes to consider how you and your team could apply Value Stream Mapping. 6 | -------------------------------------------------------------------------------- /online-devops-dojo/value-stream-mapping/intro.md: -------------------------------------------------------------------------------- 1 | ## Welcome! 2 | 3 | Welcome to the **Online DevOps Dojo** lab on Value Stream Mapping (VSM). 4 | 5 | ## Purpose 6 | 7 | The primary objective of the "Value Stream Mapping" (VSM) module is to help you to understand the principles and benefits of VSM. This is to enable you and your team to use VSM to better understand your current processes to identify and fix issues with those processes. 8 | 9 | The secondary objective is to give you an opportunity to complete a VSM real world scenario using Katacoda in **your** Sandbox environment. 10 | 11 | Remember the Sandbox is your personal clone of the Pet Clinic Repository. The Sandbox is the one which you created in the Welcome module. You are free to experiment in your Sandbox without fear of impacting the lab or other learners. 12 | 13 | By the end of the lesson and lab, you will be able to: 14 | 15 | * Explain what a Value Stream is. 16 | * Articulate what VSM is. 17 | * Describe the need for and business benefits of VSM. 18 | * Identify and select the initial Value Streams to address. 19 | * Understand the process of conducting a VSM exercise. 20 | * what to include 21 | * what to exclude 22 | * who needs to participate 23 | * what are the outputs 24 | * Use the VSM to help identify improvements that can deliver the greatest business value. 25 | -------------------------------------------------------------------------------- /online-devops-dojo/value-stream-mapping/step1.md: -------------------------------------------------------------------------------- 1 | Pet Clinic's merry bunch of people are now well underway on their DevOps 2 | journey. They have defined Improvement Themes and are running regular DevOps 3 | Kaizen events to address the delta between an ever improving current state and 4 | the desired state also known as the definition of awesome. 5 | 6 | They are from the disciplined application of the 3 ways of DevOps seeing 7 | incremental but manifest improvements to their processes. This hasn't gone 8 | unnoticed by the key stakeholders in the business, who are referring other 9 | groups in the organization to the team to help them understand how this change 10 | was carried out. 11 | 12 | **Brenda** still demands more from the team in terms of functionality delivered 13 | and quality of output. **Paulo** is still pressuring the team to commit to 14 | delivering more story points in a sprint. 15 | 16 | The difference now is that requests of that nature are not causing the panic of 17 | old. Now stakeholder requests are being analyzed, incorporated into the 18 | Improvement Themes and addressed via the DevOps Kaizen Events initiated 19 | following the VSM exercise the team performed. 20 | 21 | | | | 22 | |---|---| 23 | |![Chun](../../assets/online-devops-dojo/value-stream-mapping/chun.png)|**Chun** DevOps coach who facilitated the VSM Exercise | 24 | |![Paulo](../../assets/online-devops-dojo/value-stream-mapping/paulo.png)|**Paulo** Product Owner who led the VSM Exercise | 25 | |![Santhosh](../../assets/online-devops-dojo/value-stream-mapping/santhosh.png)|**Santhosh** Scrum Master who co-facilitated the VSM exercise | 26 | |![Brenda](../../assets/online-devops-dojo/value-stream-mapping/brenda.png)|**Brenda** Business representative in the VSM exercise | 27 | |![Selma](../../assets/online-devops-dojo/value-stream-mapping/selma.png)|**Selma** Security representative in the VSM exercise | 28 | |![Adam](../../assets/online-devops-dojo/value-stream-mapping/adam.png)|**Adam** IT Admin representative in the VSM exercise | 29 | |![Dan](../../assets/online-devops-dojo/value-stream-mapping/dan.png)|**Dan** Developer representative in the VSM exercise | 30 | |![Tina](../../assets/online-devops-dojo/value-stream-mapping/tina.png)|**Tina** Test representative in the VSM exercise | 31 | 32 | But it wasn't always that way ... 33 | -------------------------------------------------------------------------------- /online-devops-dojo/value-stream-mapping/step10-answer.md: -------------------------------------------------------------------------------- 1 | The correct answer is **Showcase and UAT** 2 | 3 | The step with the worst %C/A is **Showcase and UAT** as it has a %C/A of 50% 4 | 5 | As a reminder here is the VSM the Pet Clinic team agreed represented their E2E software development process 6 | 7 | ![](https://s3.amazonaws.com/devopsdojoassets/valuestreammap.png) 8 | -------------------------------------------------------------------------------- /online-devops-dojo/value-stream-mapping/step10.md: -------------------------------------------------------------------------------- 1 | **Learner** 2 | 3 | Here is the VSM which the Pet Clinic team have agreed represented their E2E software development process 4 | 5 | ![](../../assets/online-devops-dojo/value-stream-mapping/valuestreammap.png) 6 | 7 | >> What activity in the VSM has worst %C/A? << 8 | ( ) Change Approval 9 | (*) Showcase and UAT 10 | ( ) Design and Analysis 11 | ( ) Development & dev testing (including test automation) 12 | -------------------------------------------------------------------------------- /online-devops-dojo/value-stream-mapping/step11-verify.sh: -------------------------------------------------------------------------------- 1 | #!/bin/bash 2 | 3 | [ -f /tmp/dialog2played.txt ] && echo "done" -------------------------------------------------------------------------------- /online-devops-dojo/value-stream-mapping/step11.md: -------------------------------------------------------------------------------- 1 | The team now have their Value Stream Mapped, and now need to agree the way forward. 2 | 3 | ![](../../assets/online-devops-dojo/value-stream-mapping/team-chat.jpg) 4 | 5 | Click: `./dialog2.sh`{{execute}} 6 | 7 | And follow the dialog in the terminal window... 8 | 9 | **Note**: Don't expect a one to one mapping between activities in the current 10 | state and the desired end state Value Stream Maps. In some cases the results of 11 | the VSM exercise may be that the team that given the scale of the issues with 12 | the current state may end up creating an completely new desired state process. 13 | -------------------------------------------------------------------------------- /online-devops-dojo/value-stream-mapping/step12-answer.md: -------------------------------------------------------------------------------- 1 | The correct answer is **Release Planning & Estimation** 2 | 3 | The step with the worst activity ratio is **Release Planning & Estimation** as it has an activity ratio of 1 hour/3 weeks so of less than 0.01% 4 | 5 | As a reminder here is the VSM the Pet Clinic team agreed represented their E2E software development process 6 | 7 | ![](https://s3.amazonaws.com/devopsdojoassets/valuestreammap.png) 8 | -------------------------------------------------------------------------------- /online-devops-dojo/value-stream-mapping/step12.md: -------------------------------------------------------------------------------- 1 | **Learner** 2 | 3 | Here is the VSM the Pet Clinic team agreed represented their E2E software development process 4 | 5 | ![](../../assets/online-devops-dojo/value-stream-mapping/valuestreammap.png) 6 | 7 | >> The Overall Activity Ratio for the VSM is 14.5% which step has the worst activity ratio? << 8 | (*) Release Planning & Estimation 9 | ( ) Design Approval 10 | ( ) Design and Analysis 11 | ( ) Showcase and UAT -------------------------------------------------------------------------------- /online-devops-dojo/value-stream-mapping/step2.md: -------------------------------------------------------------------------------- 1 | Come with us on a journey, let us rewind and take to trip back in time to the Pet Clinic offices of a year ago. The reason for this trip is to better understand where the team were and how they used VSM with the support of their management to understand and change their end to end process. 2 | 3 | Fade In .. 4 | 5 | We open in an incident room strewn with coke cans, pizza boxes and stale air. 6 | 7 | The team, tired and tense, are following a long couple of days spent addressing issues following an upgrade to a key system holding a post-mortem into the issues with the upgrade. The question at hand is why another major upgrade to the system was delivered late, prone to errors and suffered periodic performance issues. 8 | 9 | **Brenda** is not happy, she is explaining to the team that this is not the first event of this nature and the impact to the business. She also outlines the effects issues of this nature are having on her and the teams credibility. 10 | 11 | It is a not a pleasant meeting, developers are blaming testers, testers are blaming developers, project managers are pointing to infrastructure issues, admins are pointing to planning issues. The only thing everyone seems to agree to is that someone else is more to blame than they are for the issues encountered. 12 | 13 | **Paulo** the product owner, who is relatively new to the company proposes VSM as an approach that could be used to help identify the root causes of the issues and provide a basis to start improving from. Paulo informs the team VSM was used extensively to great effect in his previous company. The team, eager to explore a potential solution to the challenges faced, are curious (if slightly skeptical) that a solution can be found. 14 | 15 | Paulo engages **Chun** the DevOps coach to host a session to outline VSM to the team. 16 | 17 | Chun explains that an IT Value stream is the process including all steps a team follows to get changes and feature implementations into production thus delivering business value. VSM is the process of aligning the entire team around an agreed understanding of the steps, processes, timings and constraints in a Value Stream, thus helping the team to identify, agree and prioritize improvement steps. 18 | 19 | VSM focuses the DevOps work on improvements which achieve the largest business value, thus helping organizations create blueprints in support of Lean transformations. 20 | 21 | This is **Value Stream Mapping**. 22 | -------------------------------------------------------------------------------- /online-devops-dojo/value-stream-mapping/step3-verify.sh: -------------------------------------------------------------------------------- 1 | #!/bin/bash 2 | 3 | [ -f /tmp/firstname.txt ] && echo "done" -------------------------------------------------------------------------------- /online-devops-dojo/value-stream-mapping/step3.md: -------------------------------------------------------------------------------- 1 | The team have decided to explore the use of VSM as a tool to understand and hopefully understand their processes. 2 | 3 | The remainder of this lab is a series of conversational snippets taken from that exercise the Pet Clinic team conducted. 4 | 5 | First before you continue, let's get your name: click `./prereq.sh`{{execute}} -------------------------------------------------------------------------------- /online-devops-dojo/value-stream-mapping/step4-verify.sh: -------------------------------------------------------------------------------- 1 | #!/bin/bash 2 | 3 | [ -f /tmp/dialog1played.txt ] && echo "done" -------------------------------------------------------------------------------- /online-devops-dojo/value-stream-mapping/step4.md: -------------------------------------------------------------------------------- 1 | 2 | ![](../../assets/online-devops-dojo/value-stream-mapping/team-chat.jpg) 3 | 4 | Click: `./dialog1.sh`{{execute}} 5 | 6 | And follow the dialog in the terminal window... 7 | -------------------------------------------------------------------------------- /online-devops-dojo/value-stream-mapping/step5-answer.md: -------------------------------------------------------------------------------- 1 | The correct answer is **Both** 2 | 3 | The time it takes for a feature to be delivered includes both the actual time someone works on it and the time the feature spends waiting for someone to work on it. -------------------------------------------------------------------------------- /online-devops-dojo/value-stream-mapping/step5.md: -------------------------------------------------------------------------------- 1 | >> What do you think contributes to the time it takes for a feature to be delivered? << 2 | ( ) The actual time someone works on it 3 | ( ) The time work waits 4 | (*) Both -------------------------------------------------------------------------------- /online-devops-dojo/value-stream-mapping/step6-answer.md: -------------------------------------------------------------------------------- 1 | The correct answer is **All of the above** 2 | 3 | Handoffs, Incomplete/Incorrect Processing & Queues are all reasons that work spends time waiting. -------------------------------------------------------------------------------- /online-devops-dojo/value-stream-mapping/step6.md: -------------------------------------------------------------------------------- 1 | >> Why do you think work spends time waiting? << 2 | ( ) Handoffs 3 | ( ) Incomplete/Incorrect processing 4 | ( ) Queues 5 | (*) All of the above 6 | -------------------------------------------------------------------------------- /online-devops-dojo/value-stream-mapping/step7.md: -------------------------------------------------------------------------------- 1 | With the support of management, the team have scheduled a two day session to create the VSM. 2 | 3 | Representatives from all stakeholders in the value stream, i.e. the Pet Clinic software development process, have been included. 4 | 5 | The purpose of this session is to discuss, discover and agree a shared understanding of what is currently happening in the E2E process. 6 | 7 | Paulo who is leading the exercise has stressed the importance of resisting the temptation to document what is to supposed to happen but to focus on what is actually happening. 8 | 9 | This is the VSM ![](https://s3.amazonaws.com/devopsdojoassets/valuestreammap.png) they created to represent the E2E flow. 10 | 11 | The process the team followed to create the VSM can be described as 12 | 13 | 1. **Identified the Value Stream to be mapped** - Pet Clinic Software Development Process. 14 | 15 | 2. **Empowered the team** - ensured all stakeholders represented. 16 | 17 | 3. **Agreed the problem statement** - Deliver defect free software that meets business requirements quicker and more frequently. 18 | 19 | 4. **Agreed the scope** - what parts of the process VSM was to include and just importantly, what parts it would not. 20 | 21 | 5. **Walked the process documenting** - agreed the process steps, took multiple passes through the process. 22 | 23 | 6. **Collected process data** - lead times, processing times, complete and accurate work per step. 24 | 25 | 7. **Agreed the VSM** - represented the current state of the Pet Clinic Software Development Process. 26 | 27 | 8. **Analyzed the VSM and agreed the way forward** - which the remainder of this module will cover. 28 | -------------------------------------------------------------------------------- /online-devops-dojo/value-stream-mapping/step8.md: -------------------------------------------------------------------------------- 1 | There are some points to note about the VSM 2 | 3 | ![](../../assets/online-devops-dojo/value-stream-mapping/valuestreammap.png) 4 | 5 | The symbols on the VSM are a standard set of symbols ![](../../assets/online-devops-dojo/value-stream-mapping/valuestreammap-symbols.png) 6 | 7 | Please take some time to review the Pet Clinic Software Development Process, specifically where and how the symbols have been used in the mapping of the process. 8 | 9 | As well as describing the flow, including branches and loops, for each step in the process the team have captured the following metrics 10 | 11 | **LT: Lead Time**. LT is the time it takes a work item to leave the previous step to when it leaves the current step. LT includes both the time during which value is being added to the the work item, processing time and idle time when no work is being done on the item. 12 | 13 | **PT: Processing Time**. PT is the time in the step when a work item is being productively processed. 14 | 15 | %**C/A: Percent of Complete/Accurate Work Items**. % C/A is the percent of Complete/Accurate work items received in the current step from the previous step. 16 | 17 | Capturing these metrics in the current state VSM will help the team understand the areas jeopardizing fast flow, short lead times and reliable outcomes, and thus guide the team toward identifying the desired improvements. 18 | 19 | fade out ... -------------------------------------------------------------------------------- /online-devops-dojo/value-stream-mapping/step9-answer.md: -------------------------------------------------------------------------------- 1 | The correct answer is **Release Planning & Estimation** 2 | 3 | The step with longest lead time (LT) is **Release Planning & Estimation** as it has a lead time of 3 weeks with only 1 hour of processing time (PT) 4 | 5 | As a reminder here is the VSM the Pet Clinic team agreed represented their E2E software development process 6 | 7 | ![](https://s3.amazonaws.com/devopsdojoassets/valuestreammap.png) 8 | -------------------------------------------------------------------------------- /online-devops-dojo/value-stream-mapping/step9.md: -------------------------------------------------------------------------------- 1 | Here is the VSM the Pet Clinic team agreed represented their E2E software development process 2 | 3 | ![](../../assets/online-devops-dojo/value-stream-mapping/valuestreammap.png) 4 | 5 | >> What activity has the longest lead time? << 6 | (*) Release Planning & Estimation 7 | ( ) Design Approval 8 | ( ) Show Case and Approval 9 | ( ) Production Deployment 10 | -------------------------------------------------------------------------------- /online-devops-dojo/version-control/assets/prepare.sh: -------------------------------------------------------------------------------- 1 | #!/bin/bash 2 | # This Source Code Form is subject to the terms of the Mozilla Public 3 | # License, v. 2.0. If a copy of the MPL was not distributed with this 4 | # file, You can obtain one at https://mozilla.org/MPL/2.0/. 5 | # 6 | # Globals 7 | # 8 | DEBUG=false 9 | GITHUB='github.com' 10 | GITHUBAPIURL='https://api.github.com' 11 | # Explicit header for GitHub API V3 request cf. https://developer.github.com/v3/#current-version 12 | GITHUBAPIHEADER='Accept: application/vnd.github.v3+json' 13 | 14 | COLQUESTION="\u001b[36m" 15 | COLINFO="\u001b[37m" 16 | COLLOGS="\u001b[35m" 17 | COLRESET="\u001b[m" 18 | REPO=pet-clinic 19 | ORGREPO=dxc-technology 20 | WELCOME_URL=https://dxc-technology.github.io/about-devops-dojo/katacoda/os1-welcome/ 21 | 22 | if [ "$DEBUG" = false ] ; then 23 | CURL_NODEBUG="-sS" 24 | fi 25 | 26 | # adding -s to the command line, allows to hide the PAT entered especially during demos 27 | if [ "$1" == "-s" ] ; then 28 | HIDE_PAT="-s" 29 | fi 30 | 31 | # 32 | # Ask for GitHub PAT 33 | # 34 | echo -e "${COLQUESTION}Please enter your ${GITHUB} Personal Access Token:${COLRESET}" 35 | read $HIDE_PAT TOKEN 36 | export TOKEN 37 | 38 | echo -e "${COLLOGS}Fetching your details from GitHub...${COLRESET}" 39 | USER_JSON=$(curl ${CURL_NODEBUG} -H "Authorization: token ${TOKEN}" -H "$GITHUBAPIHEADER" -X GET ${GITHUBAPIURL}/user) 40 | 41 | SHORTNAME=$(echo $USER_JSON | jq -r '.login') 42 | export SHORTNAME 43 | echo "export SHORTNAME=${SHORTNAME}" > /tmp/shortname.txt 44 | 45 | EMAIL=$(echo $USER_JSON | jq -r '.email//empty') 46 | if [ -z "$EMAIL" ]; then 47 | EMAIL=${SHORTNAME}@noemail.com 48 | fi 49 | export EMAIL 50 | 51 | git config --global user.email "${EMAIL}" 52 | 53 | # Check if repository already exists and properly populated 54 | echo -e "${COLLOGS}" 55 | curl $CURL_NODEBUG -H "Authorization: token $TOKEN" -H "$GITHUBAPIHEADER" -X GET ${GITHUBAPIURL}/repos/$SHORTNAME/$REPO/contents/Jenkinsfile | grep "Not Found" 56 | REPO_DOES_NOT_EXIST=$? 57 | if [ $REPO_DOES_NOT_EXIST -eq 0 ]; then 58 | echo -e "${COLRESET}> I'm confused..." 59 | echo -e "> I was expecting to find the $REPO repository under your GitHub username and I didn't, or the content does not look right." 60 | echo -e "> That must be me. But just in case:" 61 | echo -e "> - Close this Katacoda window: the environment will expire soon and you need ample time to complete the module" 62 | echo -e "> - Go through the Welcome module which will set everything up for you:" 63 | echo -e "> $WELCOME_URL" 64 | exit 1 65 | fi 66 | 67 | # 68 | # Clone Pet Clinic locally 69 | # 70 | echo -e "${COLINFO}Cloning $REPO Git repository...${COLRESET}" 71 | echo -e "${COLLOGS}" 72 | cd ~ 73 | rm -fR $REPO 74 | git clone https://${SHORTNAME}:${TOKEN}@${GITHUB}/${SHORTNAME}/${REPO}.git 75 | echo -e "${COLRESET}" 76 | 77 | touch /tmp/ready 78 | 79 | echo -e "${COLINFO}You are all set! Click on 'CONTINUE'.${COLRESET}" 80 | -------------------------------------------------------------------------------- /online-devops-dojo/version-control/finish.md: -------------------------------------------------------------------------------- 1 | # Conclusion 2 | 3 | Congratulations! You experienced version control: 4 | 5 | * Proposing changes within a short lived feature branch 6 | * Submit a pull request 7 | * Looked for feedback with a peer review 8 | * Iterate on the change 9 | * Merge the change in the `master` branch 10 | 11 | This process is appropriate for a small team, and can also scale for very large 12 | teams. Remember, this process is applicable to application code, but also documentation, infrastructure, and any type of text based asset. 13 | -------------------------------------------------------------------------------- /online-devops-dojo/version-control/index.json: -------------------------------------------------------------------------------- 1 | { 2 | "pathwayTitle": "Online DevOps Dojo", 3 | "title": "Version Control", 4 | "private": true, 5 | "description": "Version control is a system that records changes to a file or set of files over time so that you can recall specific versions later.", 6 | "difficulty": "intermediate", 7 | "time": "30 minutes", 8 | "details": { 9 | "steps": [ 10 | { 11 | "title": "Step 1", 12 | "text": "step1.md" 13 | }, 14 | { 15 | "title": "Step 2", 16 | "text": "step2.md", 17 | "verify": "step2-verify.sh" 18 | }, 19 | { 20 | "title": "Step 3", 21 | "text": "step3-nospell.md", 22 | "code": "step3.sh" 23 | }, 24 | { 25 | "title": "Step 4", 26 | "text": "step4.md" 27 | }, 28 | { 29 | "title": "Step 5", 30 | "text": "step5.md", 31 | "code": "step5.sh" 32 | }, 33 | { 34 | "title": "Step 6", 35 | "text": "step6.md", 36 | "code": "step6.sh" 37 | }, 38 | { 39 | "title": "Step 7", 40 | "text": "step7.md", 41 | "code": "step7.sh" 42 | } 43 | ], 44 | "intro": { 45 | "text": "intro.md" 46 | }, 47 | "assets": { 48 | "host01": [ 49 | { "file": "prepare.sh", "target": "~/","chmod": "+x" } 50 | ] 51 | }, 52 | "finish": { 53 | "text": "finish.md" 54 | } 55 | }, 56 | "environment": { 57 | "hideintro": false, 58 | "uilayout": "editor-terminal", 59 | "uieditorpath":"/root/pet-clinic", 60 | "uimessage1": "\u001b[32mYour Interactive Bash Terminal.\r\nYou can type in and run shell commands here.\r\n\u001b[m" 61 | }, 62 | "backend": { 63 | "imageid": "ubuntu" 64 | 65 | } 66 | } 67 | -------------------------------------------------------------------------------- /online-devops-dojo/version-control/intro.md: -------------------------------------------------------------------------------- 1 | ## Welcome! 2 | 3 | Welcome to the **Online DevOps Dojo** lab on Version Control. 4 | 5 | ## Purpose 6 | 7 | The primary objective of the "version control" module is to understand the 8 | benefits of version control. The secondary objective is to expose a working 9 | example of a branching model for version control: the pull request / feature 10 | branch. 11 | 12 | If you have not completed the Welcome module, you must do so before continuing 13 | with this module. 14 | 15 | By the end of the lesson and lab, you will be able to: 16 | 17 | * articulate the benefits of version control, 18 | * implement version control for your own activity, 19 | * understand the mechanism of pull requests / feature branches. 20 | -------------------------------------------------------------------------------- /online-devops-dojo/version-control/step1.md: -------------------------------------------------------------------------------- 1 | ## Version control: what for? 2 | 3 | | | | 4 | |---|---| 5 | |![](../../assets/online-devops-dojo/version-control/paulo.png)|**Paulo** wants us to support veterinarians who handle horses.
He documented several user stories in the backlog. They have been prioritized and are now ready to be implemented. 6 | |![](../../assets/online-devops-dojo/version-control/dan.png)|**Dan** is ready to work on the user stories from **Paulo**. 7 | 8 | **Previously**, Dan was not using version control. Every now and then, he has been saving his code to a directory on a file share. This quickly became a problem when more people got added to the team: it was hard to collaborate, with others overwriting changes, creating regressions which got caught late in production. Managing backups of earlier versions to keep a history of the changes was also problematic: he implemented workarounds by adding versions in the file names: `main.java`, `main-1.0.java`, `main-1.1.java` and `main-1.1.final.java`. This became unmanageable when several files had to be kept "in sync" for the application to work. Finally, the team could not easily spot what was changed between those versions, making production troubleshooting a very difficult and cumbersome activity. 9 | 10 | **Then** Dan's team invested in a proper version control system. They picked GIT, the de facto standard version control system. GIT is a Distributed Version Control System, which makes it extremely fast as it mainly runs disconnected from the network. GIT alone did not provide all of the collaboration capabilities they needed, so they started to use GitHub which wraps GIT and provides additional collaboration capabilities. 11 | 12 | | | | 13 | |---|---| 14 | |![](../../assets/online-devops-dojo/version-control/tina.png)|Not only is **Dan**'s team using version control daily, now **Tina** is using it to manage her automated test cases.
Automated test cases are managed as code, in GIT, and executed as part of the continuous delivery pipeline. 15 | |![](../../assets/online-devops-dojo/version-control/adam.png)|**Adam** is using GIT to manage his scripts to automate infrastructure (server, storage, network) configuration.
Adding more storage amounts to adding an entry in the configuration file in GIT so that it gets peer reviewed and automatically tested before being implemented in the live environment. 16 | 17 | The team chose a [branching model](https://www.atlassian.com/git/tutorials/comparing-workflows) which works for them: they use short lived feature branches which they often commit to the trunk (master). 18 | -------------------------------------------------------------------------------- /online-devops-dojo/version-control/step2-verify.sh: -------------------------------------------------------------------------------- 1 | #!/bin/bash 2 | 3 | [ -f /tmp/ready ] && echo "done" -------------------------------------------------------------------------------- /online-devops-dojo/version-control/step2.md: -------------------------------------------------------------------------------- 1 | We will now download a copy of your own personal pet-clinic GitHub repository 2 | locally by issuing a `git clone`. To streamline this process, you will get asked 3 | a few questions and a script will do it for you. 4 | 5 | **Note**: you will re-use GitHub's "Personal Access Token" you created in the 6 | Welcome module. If you need to generate a new one, go to 7 | [https://github.com/settings/tokens](https://github.com/settings/tokens) and 8 | save it for later. 9 | 10 | Let's go ahead and prepare our environment, click this: 11 | 12 | `./pet-clinic/prepare.sh`{{execute}} 13 | 14 | ...and wait for the "Click on 'CONTINUE'" message. 15 | 16 | 💡 **TIP**: 🦊 Firefox user? Use CTRL+INS / 17 | SHIFT+INS to copy/paste your Personal Access Token in the 18 | window. 19 | -------------------------------------------------------------------------------- /online-devops-dojo/version-control/step3-nospell.md: -------------------------------------------------------------------------------- 1 | # Understanding the user story 2 | 3 | ![Paulo](../../assets/online-devops-dojo/version-control/paulo.png) 4 | 5 | > I created a user story, and it is visible in our backlog. We want to link the 6 | > code changes to that user story, so that we can ensure traceability and make 7 | > work visible. 8 | 9 | ## Steps 10 | 11 | * Go and check the pet clinic backlog (check the terminal window for a link to the issues module in your pet-clinic repository). 12 | * Identify the user story number (should be `1`) 13 | 14 | # Create a feature branch 15 | 16 | ![Dan](../../assets/online-devops-dojo/version-control/dan.png) 17 | 18 | > To make sure we isolate work, we use feature branches. We name this short lived 19 | > branch after the ID and name of the user story 20 | 21 | ## Steps 22 | 23 | * Change directory into the cloned repo: `cd pet-clinic`{{execute}} 24 | * Create `us-1-horse` branch to cover user story 1 about adding horses: `git checkout -b us-1-horse`{{execute}} 25 | 26 | ![Dan](../../assets/online-devops-dojo/version-control/dan.png) 27 | 28 | > This branch is a short lived (e.g. one day) feature branch. We use this feature branch to 29 | > get feedback from continuous integration (automated checks and gates) and from peers. 30 | > This allows us to work in isolation (without impacting others), yet sharing the work in progress. 31 | 32 | # Make changes 33 | 34 | ![Dan](../../assets/online-devops-dojo/version-control/dan.png) 35 | 36 | > Now, let's implement the user story by making some changes in the code. We will first start by adding `horse` as a pet type. 37 | 38 | ## Steps 39 | 40 | * In the editor to the right, head to `src/main/resources/db/hsqldb` folder and open `data.sql` 41 | * Below `INSERT INTO types VALUES (6, 'hamster');` around line 23, add a new line to insert the horse entry: `INSERT INTO types VALUES (7, 'horse');`{{copy}} 42 | Note that changes are saved automatically. 43 | * Check the branch in which you are working: `git branch`{{execute}} 44 | * Check the status of the file changed: `git status`{{execute}} 45 | 46 | ![Dan](../../assets/online-devops-dojo/version-control/dan.png) 47 | 48 | > Good! I can see that you are working in the context of the feature branch and that 49 | > the file has changed, ready to be added: Git reports that changes are not staged for commit yet. 50 | -------------------------------------------------------------------------------- /online-devops-dojo/version-control/step3.sh: -------------------------------------------------------------------------------- 1 | source /tmp/shortname.txt 2 | echo -e "Go to the repository to see user stories: https://github.com/${SHORTNAME}/pet-clinic/issues" -------------------------------------------------------------------------------- /online-devops-dojo/version-control/step4.md: -------------------------------------------------------------------------------- 1 | # Add, commit and push 2 | 3 | ![Dan](../../assets/online-devops-dojo/version-control/dan.png) 4 | 5 | > Let's add the change to the staging area. In other words, that we have marked a modified file in its current version to go into our next commit snapshot. 6 | > Then, let's commit locally and push back to our GitHub repository 7 | 8 | ## Steps 9 | 10 | * Add to modified files to the staging area: `git add *`{{execute}} 11 | * Now the changes are put to staging area and are ready to be committed. Let's check the status before committing: `git status`{{execute}} 12 | * Let's commit in our local repository: `git commit -m "#1: add support for horses in database initialization"`{{execute}} 13 | * Alternatively, you can also try simply `git commit`{{execute}}: this will open an editor to enter a more detailed commit message. 14 | * Push the changes back to the central repository: `git push -u origin us-1-horse`{{execute}} 15 | 16 | The changes are pushed to GitHub, as part of the feature branch which you named `us-1-horse`. 17 | -------------------------------------------------------------------------------- /online-devops-dojo/version-control/step5.md: -------------------------------------------------------------------------------- 1 | # Create a Pull Request 2 | 3 | ![Dan](../../assets/online-devops-dojo/version-control/dan.png) 4 | 5 | > Although we pushed the new code back to GitHub, it is still in its isolated branch, 6 | > not impacting the work of others in the team. 7 | > It's now time to seek feedback and create a pull request so that the changes 8 | can be reviewed. 9 | 10 | ## Steps 11 | 12 | * Go to GitHub, in the pet clinic repository (check the terminal window for a link to the issues module in your pet-clinic repository) 13 | https://github.com/YOUR_SHORTNAME/pet-clinic (use your actual GitHub user name). 14 | * Click on 'Compare & pull request'. 15 | * Check that the title of the pull request is `#1: add support for horses in database initialization` which corresponds to the first line of your commit message. 16 | * Enter the comments and review your changes and click on 'Create pull request'. 17 | 18 | ✏ **Note**: The title of the pull request, which references a user story in GitHub matters: once the pull request is merged, the corresponding user story (GitHub issue #1) will be automatically closed. 19 | 20 | ✏ **Note**: A GitHub pull request can be used to merge Branches (as is the case here) or to import changes from a Forked repository. For a brief explanation of the pull request workflow see [Understanding the GitHub flow](https://guides.github.com/introduction/flow/). 21 | -------------------------------------------------------------------------------- /online-devops-dojo/version-control/step5.sh: -------------------------------------------------------------------------------- 1 | source /tmp/shortname.txt 2 | echo -e "Go to the repository to create a pull request: https://github.com/${SHORTNAME}/pet-clinic" -------------------------------------------------------------------------------- /online-devops-dojo/version-control/step6.md: -------------------------------------------------------------------------------- 1 | # Peer review 2 | 3 | ![Dan](../../assets/online-devops-dojo/version-control/dan.png) 4 | 5 | > OK, you submitted your changes. They are ready to be reviewed by someone 6 | > before they get merged. 7 | > Let's ask for a lightweight peer review within the pull request. 8 | 9 | ## Steps 10 | 11 | * In the pull request you have just created, enter a comment to ask for a review from **Paulo**, our product owner: `/paulo - can you please review this pull request?`{{copy}} (It's important you type the comment exactly like that for the lab to work - you may want to copy/paste the comment). 12 | * Paulo will provide its comments. 13 | * Back to the editor, change the code according to Paulo's comments. 14 | * Let's push the code back to GitHub: 15 | * `git status`{{execute}}: where are we? What are the files which have been changed? 16 | * `git add .`{{execute}}: adding all the files in the current directory (`.`) in the staging area 17 | * `git commit -m "Taking Paulo's comments into account"`{{execute}}: commit the changes in the local repository 18 | * `git push`{{execute}}: push the changes back to GitHub 19 | 20 | * From the pull request, ask Paulo for another review by adding a new comment: `/paulo - can you check now?`{{copy}} 21 | * Once Paulo is happy with the changes, **Paulo** will merge the pull request. 22 | 23 | 🤖 **Note**: Paulo is a bot, implemented as a "[GitHub app](https://developer.github.com/apps/about-apps/)". Its code is here: . 24 | -------------------------------------------------------------------------------- /online-devops-dojo/version-control/step6.sh: -------------------------------------------------------------------------------- 1 | source /tmp/shortname.txt 2 | echo -e "Go to the repository to create a pull request: https://github.com/${SHORTNAME}/pet-clinic" -------------------------------------------------------------------------------- /online-devops-dojo/version-control/step7.md: -------------------------------------------------------------------------------- 1 | # User story is ongoing 2 | 3 | ![Santhosh](../../assets/online-devops-dojo/version-control/santhosh.png) 4 | 5 | > I see that you have worked on the changes as per the user story, 6 | > you submitted them in GitHub, and Paulo has reviewed and merged your changes. 7 | > Are we done now? 8 | 9 | ![Dan](../../assets/online-devops-dojo/version-control/dan.png) 10 | 11 | > No Santhosh. We are meeting the first acceptance criteria, but there is more work 12 | > to be done. We can't close the user story just now. 13 | 14 | ![Santhosh](../../assets/online-devops-dojo/version-control/santhosh.png) 15 | 16 | > Yes, that was a trap! The user story stays opened until we meet all of the acceptance 17 | > criteria. 18 | 19 | ## Steps 20 | 21 | * Go and check the Pet Clinic backlog to inspect the user story (check the 22 | terminal window for a link to the issues module in your pet-clinic repository) 23 | * Verify that there is a link between the user story and the pull request which 24 | implements the user story 25 | * Verify that the user story is not closed. Don't close it yet. 26 | -------------------------------------------------------------------------------- /online-devops-dojo/version-control/step7.sh: -------------------------------------------------------------------------------- 1 | source /tmp/shortname.txt 2 | echo -e "Link to your user stories: https://github.com/${SHORTNAME}/pet-clinic/issues" -------------------------------------------------------------------------------- /online-devops-dojo/welcome/assets/github-issues.py: -------------------------------------------------------------------------------- 1 | #!/usr/bin/python3 2 | # Python helper to create GitHub issues, except if they already exist 3 | 4 | # This Source Code Form is subject to the terms of the Mozilla Public 5 | # License, v. 2.0. If a copy of the MPL was not distributed with this 6 | # file, You can obtain one at https://mozilla.org/MPL/2.0/. 7 | 8 | import os, sys, json, requests, yaml 9 | 10 | # Color constants 11 | # Reference: https://gist.github.com/chrisopedia/8754917 12 | COLINFO="\033[0;35m" 13 | COLRESET="\033[m" 14 | 15 | baseurl = 'https://api.github.com' 16 | headers = {"Content-Type": "application/json", "Accept": "application/vnd.github.v3+json"} 17 | user = os.environ['SHORTNAME'] 18 | token = os.environ['TOKEN'] 19 | repo = user + '/pet-clinic' 20 | 21 | if len(sys.argv) != 2: 22 | print(" Usage: " + sys.argv[0] + " github-issues.yaml") 23 | sys.exit(0) 24 | 25 | def main(): 26 | print(COLINFO + "Create user stories as GitHub issues..." + COLRESET) 27 | 28 | # Command line argument: issues as yaml file 29 | issues_file = sys.argv[1] 30 | 31 | # read the issues 32 | try: 33 | issues = yaml.load_all(open(issues_file, 'r'), Loader=yaml.FullLoader) 34 | except yaml.YAMLError as exc: 35 | print(COLINFO + exc + COLRESET) 36 | 37 | # Create the issues 38 | for issue in issues: 39 | # Avoid creating an issue which is already there (same title) 40 | issue_already_exists = False 41 | # List all open issues 42 | payload = json.dumps({ 43 | "state" : "open" 44 | }) 45 | sys.stdout.write(COLINFO + "." + COLRESET) 46 | sys.stdout.flush() 47 | response = requests.get(baseurl + "/repos/" + repo + "/issues", 48 | data=payload, 49 | headers=headers, 50 | auth=(user, token)) 51 | if response.status_code == 200: 52 | issues_opened = json.loads(response.text) 53 | for issue_found in issues_opened: 54 | if (issue_found['title'] == issue['title']): 55 | # This issue has the same title has the one we want to create. Skipping. 56 | issue_already_exists = True 57 | 58 | if (not issue_already_exists): 59 | payload = json.dumps({ 60 | "title" : issue['title'], 61 | "body": issue['body'], 62 | "labels" : issue['labels'] 63 | }) 64 | response = requests.post(baseurl + "/repos/" + repo + "/issues", 65 | data=payload, 66 | headers=headers, 67 | auth=(user, token)) 68 | if response.status_code != 201: 69 | # An error occured 70 | print(COLINFO + "Error adding issue " + issue['title'] + ": " + str(response.status_code) + " " + response.text + COLRESET) 71 | else: 72 | sys.stdout.write(COLINFO + "." + COLRESET) 73 | sys.stdout.flush() 74 | print(COLRESET) 75 | 76 | main() 77 | -------------------------------------------------------------------------------- /online-devops-dojo/welcome/assets/github-issues.yaml: -------------------------------------------------------------------------------- 1 | --- 2 | title: Support veterinarians who handle horses 3 | body: "From **Paulo**:\r![](https://s3.amazonaws.com/devopsdojoassets/paulo.png)\r\r>**As a** product owner,\r**I want** horse type entries when the pet clinic database is initially populated,\r**so that** I can demo the feature to veterinarians who take care of horses.\r\r**Acceptance criteria**:\r* One can have horse as pet\r* The test data contains new pet names for horses" 4 | labels: [":bulb: user_story", "P1", "3"] 5 | -------------------------------------------------------------------------------- /online-devops-dojo/welcome/assets/github-labels.yaml: -------------------------------------------------------------------------------- 1 | --- 2 | name: ":bug: bug" 3 | description: 4 | color: 0052cc 5 | --- 6 | name: ":bulb: user_story" 7 | description: 8 | color: 0052cc 9 | --- 10 | name: ":sparkles: epic" 11 | description: 12 | color: 0052cc 13 | --- 14 | name: P1 15 | description: "Priority 1" 16 | color: fbca04 17 | --- 18 | name: P2 19 | description: "Priority 2" 20 | color: fbca04 21 | --- 22 | name: P3 23 | description: "Priority 3" 24 | color: fbca04 25 | --- 26 | name: "1" 27 | description: "1 story point" 28 | color: 0e8a16 29 | --- 30 | name: "2" 31 | description: "2 story points" 32 | color: 0e8a16 33 | --- 34 | name: "3" 35 | description: "3 story points" 36 | color: 0e8a16 37 | --- 38 | name: "5" 39 | description: "5 story points" 40 | color: 0e8a16 41 | --- 42 | name: "8" 43 | description: "8 story points" 44 | color: 0e8a16 45 | --- 46 | name: "13" 47 | description: "13 story points" 48 | color: 0e8a16 49 | --- 50 | name: "21" 51 | description: "21 story points" 52 | color: 0e8a16 53 | -------------------------------------------------------------------------------- /online-devops-dojo/welcome/finish.md: -------------------------------------------------------------------------------- 1 | # Conclusion 2 | 3 | ![](../../assets/online-devops-dojo/welcome/octocat.png) 4 | 5 | This is it, my work here is done. 6 | 7 | You are now all set to start your Online DevOps Dojo. 8 | 9 | Buckle up we are going on an adventure, where we are going we don't need roads 🚀 ... 10 | -------------------------------------------------------------------------------- /online-devops-dojo/welcome/index.json: -------------------------------------------------------------------------------- 1 | { 2 | "pathwayTitle": "Online DevOps Dojo", 3 | "private": true, 4 | "description": "Getting started with the Online DevOps Dojo: understanding the back story, setting up your environment.", 5 | "time": "30 minutes", 6 | "details": { 7 | "steps": [ 8 | { 9 | "title": "The story", 10 | "text": "step1.md" 11 | }, 12 | { 13 | "title": "The characters", 14 | "text": "step2.md" 15 | }, 16 | { 17 | "title": "Setup the Pet-Clinic repository", 18 | "text": "step3.md", 19 | "verify": "step3-verify.sh" 20 | }, 21 | { 22 | "title": "Setup the DevOps Dojo bot", 23 | "text": "step4.md" 24 | } 25 | ], 26 | "intro": { 27 | "text": "intro.md" 28 | }, 29 | "assets": { 30 | "host01": [ 31 | { "file": "copy-pet-clinic.sh", "target": "~/", "chmod": "+x" }, 32 | { "file": "github-labels.py", "target": "~/", "chmod": "+x" }, 33 | { "file": "github-issues.py", "target": "~/", "chmod": "+x" }, 34 | { "file": "github-labels.yaml", "target": "~/"}, 35 | { "file": "github-issues.yaml", "target": "~/"} 36 | ] 37 | }, 38 | 39 | "finish": { 40 | "text": "finish.md" 41 | } 42 | }, 43 | "environment": { 44 | "hideintro": false, 45 | "uilayout": "terminal", 46 | "uimessage1": "\u001b[32mYour Interactive Bash Terminal.\r\nYou can type in and run shell commands here.\r\n\u001b[m" 47 | }, 48 | "backend": { 49 | "imageid": "ubuntu" 50 | } 51 | } 52 | -------------------------------------------------------------------------------- /online-devops-dojo/welcome/intro.md: -------------------------------------------------------------------------------- 1 | ## Welcome! 2 | 3 | Welcome. I am the Octocat for the **Online DevOps Dojo** Katacoda course 4 | 5 | ![](../../assets/online-devops-dojo/welcome/octocat.png) 6 | 7 | You are about to enter another dimension, a dimension not only of sight and sound but of mind. A journey into a wondrous land of imagination. Next stop, the **Online DevOps Dojo**! 8 | 9 | In addition to a Welcome and Setup module, this course is made up of 7 open source modules on DevOps culture and practices. 10 | 11 | * Leading Change 12 | * Version Control 13 | * Continuous Integration 14 | * Shift Left On Security 15 | * Value Stream Mapping 16 | * DevOps Kaizen 17 | * Post Incident Practices 18 | 19 | ## Katacoda environment 20 | 21 | The modules make use of Katacoda environments. Those are ephemeral environments which are created just for you, on the fly. They 22 | will time out after one hour. The good news is that you can explore around and get out of the script: it is your own environment. 23 | 24 | So, go grab a cup of your favorite caffeinated beverage, close your email, put your phone on plane mode, and let's get started! 25 | 26 | ## Welcome module 27 | 28 | In this Welcome module lab, we will get you started and setup a dedicated environment for you, to allow you complete the labs for 29 | the other modules in the **Online DevOps Dojo** at your own pace. 30 | 31 | First, to begin let us introduce you to the story of a business formed by the CEO Charlie, a DevOps team, an application and its 32 | delivery chain (continuous delivery pipeline). 33 | 34 | Once upon a time, not so long ago in a galaxy not so far away... 35 | 36 | ![](../../assets/online-devops-dojo/welcome/onceuponatime.jpg) 37 | -------------------------------------------------------------------------------- /online-devops-dojo/welcome/step1.md: -------------------------------------------------------------------------------- 1 | 2 | This is a story of a business, a team, an application and its delivery chain (their continuous delivery pipeline). 3 | 4 | The team is part of the IT organization of a large Pet Clinic. The Pet Clinic runs its business on a Java application. The 5 | application includes features to manage a list of clients (pet owners), their pets, and a list of veterinarians with their 6 | specialties. 7 | 8 | The Pet Clinic IT team develops, tests, deploys and supports the Java application. 9 | 10 | ![Pet Clinic application](../../assets/online-devops-dojo/welcome/petclinic.jpg) 11 | 12 |
💡 **TIP**: Adjust the window size vertical scroller to make the welcome module easier to read ◀▶
13 | -------------------------------------------------------------------------------- /online-devops-dojo/welcome/step3-verify.sh: -------------------------------------------------------------------------------- 1 | #!/bin/bash 2 | 3 | [ -f /tmp/petclinic_ready ] && echo "done" -------------------------------------------------------------------------------- /online-devops-dojo/welcome/step4.md: -------------------------------------------------------------------------------- 1 | Throughout the modules, you will interact with the virtual team, in the 2 | context of issues or pull requests. This is done through a [GitHub Application](https://developer.github.com/apps/about-apps/) 3 | which you need to "install" in your pet-clinic repository. 4 | 5 | * Go to the Online DevOps Dojo coach web site: 6 | 7 | ![Dojo coach](../../assets/online-devops-dojo/welcome/probot.jpg) 8 | 9 | * Click "Install". 10 | * If your account belongs to organization(s), you will see a first page 11 | "Where do you want to install Online DevOps Dojo Coach?", select your user profile. 12 | * In "Install on your personal account [...]" click "Only select repositories" and select `your-github-username/pet-clinic`. 13 | * Scroll down and click "Install". 14 | 15 | You will get a confirmation at the top of the browser: 16 | "**Okay, Online DevOps Dojo coach was installed on the @your-github-username account**". 17 | -------------------------------------------------------------------------------- /package.json: -------------------------------------------------------------------------------- 1 | { 2 | "name": "online-devops-dojo-coach", 3 | "version": "1.0.1", 4 | "description": "The Online DevOps Dojo coach interacts with student's PR in Katacoda trainings.", 5 | "author": "No user", 6 | "license": "MPL-2.0", 7 | "repository": "https://github.com/dxc-technology/online-devops-dojo.git", 8 | "homepage": "https://dxc-technology.github.io/about-devops-dojo/", 9 | "bugs": "https://github.com/dxc-technology/online-devops-dojo/issues/new/choose", 10 | "keywords": [ 11 | "DevOps", 12 | "Dojo", 13 | "Katacoda", 14 | "GitHub Actions" 15 | ], 16 | "scripts": { 17 | "dev": "nodemon", 18 | "start": "probot run ./index.js", 19 | "lint": "eslint", 20 | "eslint:github-action": "eslint functions/**", 21 | "test": "jest && standard", 22 | "test:watch": "jest --watch --notify --notifyMode=change --coverage" 23 | }, 24 | "dependencies": { 25 | "@probot/serverless-lambda": "0.5.0", 26 | "minimist": "^1.2.5", 27 | "node": "^12.19.0", 28 | "probot": "^9.15.1" 29 | }, 30 | "devDependencies": { 31 | "eslint": "^6.8.0", 32 | "eslint-config-prettier": "^6.13.0", 33 | "jest": "^25.5.4", 34 | "nock": "^12.0.3", 35 | "nodemon": "^2.0.6", 36 | "prettier": "1.19.1", 37 | "smee-client": "^1.2.2", 38 | "standard": "^14.3.4" 39 | }, 40 | "engines": { 41 | "node": ">= 8.3.0", 42 | "npm": ">6.0.0" 43 | }, 44 | "standard": { 45 | "env": [ 46 | "jest" 47 | ] 48 | }, 49 | "nodemonConfig": { 50 | "exec": "npm start", 51 | "watch": [ 52 | ".env", 53 | "." 54 | ] 55 | }, 56 | "jest": { 57 | "testEnvironment": "node" 58 | } 59 | } 60 | --------------------------------------------------------------------------------