{}

Airwalk Patterns

This repo is the master of any Airwalk developed patterns and/or documentation. The below is a guide on how content might be created. An example template is included here

If you're looking on how to get started writing content read CONTRIBUTING.md

• Airwalk Patterns
  • Taxonomy
    • Pattern
    • Accelerator
  • Pattern Structure
    • Introduction (_index.md)
      • Frontmatter
      • Overview
      • Use Cases
    • Architecture (architecture.md)
    • Risk (risk.md)
    • Solutions Brief (brief.md)%

Taxonomy

For the avoidance of confusion, we will use the below terminology to describe the artifacts that we will produce.

Pattern

An architecture / design document describing a product, service or component and:

• how it should be used
• where it should be used (and where it shouldn't be used)
• common constraints, dependencies
• risks, controls, data points (to monitor)

Patterns should be split into multiple sub-patterns where there is deviation in either technical approach (i.e. the differences between multiple cloud providers) or where there are components of the pattern that can/should be re-used across multiple patterns (i.e. a deployment pipeline). These sub-patterns will be referenced from any parent pattern programmatically in the near future. For now, we will capture the links in the main frontmatter.

Accelerator

A reference deployment of a pattern onto a specific Platform. Should ideally be in Terraform or another declarative language. Any code and documentation for the code should be in a separate repo, referenced in the Pattern.

Pattern Structure

Every pattern should be in a separate directory in snake_case - i.e. "/egress_proxy" The first file in the directory should be "_index.md" - this is the introduction.

Introduction (_index.md)

Frontmatter

title: Name of pattern (i.e. "Egress Pattern")
accelerator: url of associated IaC module(s) (github/ado link)
linked_patterns: [list of linked patterns (directory name)]

Overview

• Summary - an overview of the pattern
• Type - what type of product/service is the pattern for (IaaS/PaaS/SaaS) and description
• Access Type - how the user and administrators access the product/service
• Location - relevant for IaaS/PaaS/SaaS mainly, but describing if it is a local, metro, regional or global service

Use Cases

Patterns for use and any anti-patterns.

Architecture (architecture.md)

see README_architecture.md

Risk (risk.md)

For each of:

• Data Confidentiality
• Data Integrity
• Data Availability

Populate a table similar to the following:

| Risk ID | Risk Summary | Potential Impact | | --- | --- | --- | | LEAVE BLANK | | |

Solutions Brief (brief.md)

A one (or 2) pager which describes where we have delivered this capability before. Headings:

• The Client (optional)
• The Requirement and Challenges
• The Solution
• The Outcome and Benefits

Changed files

pip install gitpython

from git import Git
from datetime import date
import datetime as DT

time_period = 'days=1'

def get_the_changed_components(time_period, otype):
    g = Git() # repo directory points to `main`
    today = date.today()
    since = today - time_period #some times ago
    loginfo = g.log('--since={}'.format(since), '--pretty=tformat:', '--name-only', '--diff-filter={}'.format(otype))
    files = loginfo.split('\n')
    paths = []
    for file in files:
        paths.append(file)
    return(paths)


time_period = DT.timedelta(days=1)
files_added = get_the_changed_components(time_period, 'A')
files_changed = get_the_changed_components(time_period, 'M')
files_deleted = get_the_changed_components(time_period, 'D')

print('-----Added Files------')
for file in files_added:
  print(file)

print('-----Changed Files------')
for file in files_changed:
  print(file)