Skip to content

Commit

Permalink
#168 review updates
Browse files Browse the repository at this point in the history
  • Loading branch information
@philspokas
philspokas committed Apr 28, 2021
1 parent 359a631 commit f069236
Show file tree
Hide file tree
Showing 4 changed files with 50 additions and 71 deletions.
33 changes: 15 additions & 18 deletions docs/devops-guidelines/Configuration-Management.md
View file
Original file line number Diff line number Diff line change
Expand Up @@ -4,36 +4,33 @@

|Capability|Ideal State|Tools In Inventory|
|--|--|--|
|Infrastructure Provisioning|Infrastructure is provisioned and configured as code along with the rest of the workload in an automated CI/CD pipeline|AWS CloudFormation, Azure Resource Manager|
|Infrastructure Configuration|Infrastructure is provisioned and configured as code along with the rest of the workload in an automated CI/CD pipeline|AWS Config, AWS CLI, Azure Policy, Azure CLI|
|Application Provisioning|Automatically create application CI in ServiceNow based on what gets deployed; users and administrators provisioned with proper access|ServiceNow, AzureAD, Okta|
|Application Configuration|Configuration settings are exposed based on user roles. Changes to configuration items are audited and sent through and appropriate approval process.|AWS OpWorks|
|Infrastructure Provisioning|Infrastructure is provisioned and configured as code along with the rest of the workload in an automated CI/CD pipeline|Terraform, AWS CloudFormation, Azure Resource Manager|
|Infrastructure Configuration|Infrastructure is provisioned and configured as code along with the rest of the workload in an automated CI/CD pipeline|Terraform, AWS Config, AWS CLI, Azure Policy, Azure CLI|
|Application Provisioning|Provision via Continuous Deployment pipeline using GitHub Actions, Azure Pipelines, or similar; users and administrators provisioned with proper access|Azure DevOps, GitHub|
|Application Configuration|Configuration settings are exposed based on user roles. Changes to configuration items are audited and sent through and appropriate approval process.||

**Infrastructure Provisioning**
- Infrastructure will be provisioned using AWS CloudFormation templates. This will allow the team to standardize on a tool several team members already know that the company is licensed for, has support for from AWS and will allow us to take advantage of all AWS native capabilities. DCX is not intended to be cloud agnostic as it must take advantage of vendor specific services, e.g. CloudFront.
- Infrastructure will be provisioned using Terraform templates. This will allow the team to standardize on a tool several team members already know that the company is licensed for, is supported for common cloud platforms and provides provisiong of most native capabilities.

- All CloudFormation templates will be stored in Azure DevOps and deployed use the Azure DevOps deployment pipeline.
- All provisioning templates regardless of technology will be stored in git repos and deployed use the pipeline toofl of choice such as GitHub Actions or Azure DevOps Pipelines.

- Infrastructure provisioning will follow the [resource naming guidelines](https://phillips66.sharepoint.com/sites/IT_CloudRunway/DOH/Pages/Resource%20Naming.aspx) and [tagging guidelines](https://phillips66.sharepoint.com/sites/IT_CloudRunway/DOH/Pages/Resource%20Tags.aspx) outlined by CloudRunway.
- Infrastructure provisioning should follow [resource naming guidelines](todo ) and [tagging guidelines](todo ) .

**Infrastructure Configuration**
- Since all resources will be deployed and configured via code (Terraform, CloudFormation, etc.), configurations will be stored in version control (Git Repo).

- Any updates will be reviewed via a Pull Request, then can be deployed by the service of choice. Terraform and CloudFormation both have the capability to update existing resources if possible, and if not, they'll replace any resources that cannot be updated in place.
- Any updates will be reviewed via a Pull Request, then can be deployed by the service of choice. Terraform has the capability to update existing resources or replace resources that cannot be updated in place.

**Application Provisioning**
- Applications will consist primarily of cloud services and AWS Lambda functions and will be designed to be serverless.

- They will be provisioned using the [AWS Serverless Application Model (AWS SAM)](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/what-is-sam.html) templates.
It is critical that any resource that maintains state (databases, blob storage, aka a stateful resource) be backed up and restorable in the event of a resource replacement, or, stateful resources should be excluded from full automated provisioning.

- The templates will be stored in Azure DevOps and deployed using the Azure DevOps deployment pipeline.
**Application Provisioning**
- Applications should be provisioned via automated pipelines
- Pipeline templates will be stored in git repos along with the the application code

**Application Configuration**
- Application configuration information will be stored in different places depending on the vendor.

- AWS Lambda functions will be configured according to the [AWS guidelines](https://docs.aws.amazon.com/lambda/latest/dg/lambda-configuration.html).
- Non secret application configuration information should be stored with source code.

- Sensitive information, e.g., passwords or API keys, will be stored in [AWS Secrets Manager](https://aws.amazon.com/secrets-manager/) based on guidelines to be provided by CloudRunway.
- Sensitive information, passwords or API keys, should be stored in a cloud native secret store, or, the pipeline tool of choice.

- MuleSoft configuration will be stored and managed according to the MuleSoft best practices. For more information on MuleSoft, go to the [MuleSoft site on Teams](https://teams.microsoft.com/l/team/19%3a90fdb0298b62405187a92b6ef779571d%40thread.skype/conversations?groupId=c3720085-0e68-401d-b28f-cdbf3ca059db&tenantId=4febecd1-b635-4bb7-96fd-6688487e52f1).
- Secrets based only on deployment environment can be

53 changes: 25 additions & 28 deletions docs/devops-guidelines/Create.md
View file
Original file line number Diff line number Diff line change
Expand Up @@ -8,28 +8,35 @@ These guidelines are intended to be general guidance and will be applicable to m
For technical and software projects, a variety of artifacts are created. All artifacts should be maintined in git based repos

- Design artifacts such as high level designs, information architecutre, wire frames and similar should be committed to source and associated with a User Story whenever possible
- Software developers create code in a branch created from a User Story or Bug/Defect

All artifacts

Branching Strategies
Repository Structure
- Software developers should create code in a branch created from a User Story or Bug/Defect

todo: Branching Strategies
todo: Repository Structure

**Capabilities Inventory**

|Capability|Ideal State|Tools In Inventory|
|Capability|Ideal State|Typical Tools|
|--|--|--|
|Design|Designs are driven by user stories, captured ahead of development and vetted against a Definition of Ready (DoR) for design acceptance. Design documents incorporate all aspects of the design, to include at a minimum UX/UI, infrastructure, data models, logic and integration. Design may optionally include a clickable prototype or a proof of concept.|Adobe XD, Zeplin, Adobe Photoshop, Adobe Illustrator|
|Implementation|Developers work on tasks tied to user stories. Unit tests are developed for acceptance criteria defined in the design ahead of development of the actual product. Tasks are completed in priority order. Development is accelerated by the use of IDEs and feedback tools.|Visual Studio, Visual Studio Code, MuleSoft, SQL Server Management Studio, Oracle SQL Developer, PL/SQL Developer, Automation Anywhere, PgAdmin, Resharper
|Version Control|All artifacts are versioned and revisions to those artifacts are tracked by a version control system. Merges are simple and reversion to a "known-good state" is easy. The version control system supports distributed development and forms the backbone for the build/deployment pipelines.|git based Azure DevOps Repos |
|Implementation|Developers work on tasks tied to user stories. Unit tests are developed for acceptance criteria defined in the design ahead of development of the actual product. Tasks are completed in priority order. Development is accelerated by the use of IDEs and feedback tools.|Visual Studio, Visual Studio Code, MuleSoft, SQL Server Management Studio, Oracle SQL Developer, PL/SQL Developer, Resharper
|Version Control|All artifacts are versioned and revisions to those artifacts are tracked by a version control system (git). Merges are simple and reversion to a "known-good state" is easy. The version control system supports distributed development and forms the backbone for the build/deployment pipelines.|GitHub, git based Azure DevOps Repos, et.al. |

# Design
Designs may consist of wireframes, mockups or prototypes. A wireframe is a low-fidelity visual representation of the site and will be used to depict the basic UI, detailing the layout and structure of the site. A mockup is a mid to high-fidelity visual representation of the site and will be used to highlight color scheme, visual style and typography. A prototype is a high-fidelity visual representation of the site and will be used to simulate user interaction by allowing the user to experience the content through clickable elements and interactions. In the event the design process needs to be accelerated, wireframes may be substituted with mockups.
Designs typically consist of wireframes, mockups or prototypes.
- A wireframe is a low-fidelity visual representation of the site and will be used to depict the basic UI, detailing the layout and structure of the site.
- A mockup is a mid to high-fidelity visual representation of the site and will be used to highlight color scheme, visual style and typography.
- A prototype is a high-fidelity visual representation of the site and will be used to simulate user interaction by allowing the user to experience the content through clickable elements and interactions.

Designs will utilize Material Design, Font Awesome Icons and custom components. Phillips 66 brand guidelines will influence design concept and style.
## Design Guidelines
Use the design that meets your needs. We recommend starting with wireframes, using mockups and prototypes when necessary and their value is clear.

Designs will be reviewed by the design team, development team and business analysts before handing off for development. User stories, acceptance criteria and UX personas are used to approve and validate designs. Optionally, user testing may be included in design review.
- Designs should utilize an existing design system such as Material Design, as well as standardized componenents such as Font Awesome Icons and custom components.
- Do not develop eponymous designs unless they are truly required for differentiation.
- Beware existing or complementary solutions.
- Regardless of design, usability should not be sacrified: value something that works well over somthing that looks pretty
- When possible, include user testing in design review.

Designs should be reviewed by stakeholders and users, as well as the design team, development team and business analysts before finalization. User stories, acceptance criteria and UX personas are used to approve and validate designs.

# Implementation
Implementation is where the rubber meets the road. The plans are laid. The user stories are written. The test cases have been identified and it's finally time to build something.
Expand All @@ -39,28 +46,18 @@ Implementation will follow the SCRUM methodology and utilize Test Driven Develop
All development is expected to be performed using Visual Studio Code, Mulesoft Anypoint Studio and Eclipse.

## Source Management

Git repos in Azure DevOps are preferred.

Associate check ins using the #<work item number> in comments with Work Items to automatically generate release information as well as generate an audit trail

All code is to be checked into a version control system on a regular basis. More frequent check-ins provide benefits:
- Team members can synchornize changes reducing efforts to code merge and staying up to date on changes
- Continous integration builds can be triggered to verify code

[Learning git](https://docs.microsoft.com/en-us/azure/devops/learn/git/what-is-git)
Associate commits using user stories using the syntax "#<work item number> ..." in commit messsages to track which user story the commit is for. This generates a source audit trail and can be used by release systems to track which stories are being delivered in a release.

Code should be committed on a regular basis. More frequent commits provide benefits:
- Team members can merge committed changes more often reducing overall merge effort
- Continous integration builds can be triggered to verify code when it is committed

## Coding Standards
Developers will follow the appropriate coding standards for the languages being used. Coding standards can be found at the following locations:

* [Phillips 66 C# Coding Standard](https://phillips66.sharepoint.com/sites/IT_AE66PMO/Digital%20Capability/Shared%20Documents/2.2%20-%20IN%20-%20Business%20Improvement/WS%20-%20DCX/Working%20Documents/10.%20Development%20Standards/Phillips%2066%20C%20Sharp%20Coding%20Standard.docx?d=wde85208bab2c413e9412f255d55f1ce6&csf=1&e=LaONdH)
* [Phillips 66 JavaScript Coding Standard](https://phillips66.sharepoint.com/sites/IT_AE66PMO/Digital%20Capability/Shared%20Documents/2.2%20-%20IN%20-%20Business%20Improvement/WS%20-%20DCX/Working%20Documents/10.%20Development%20Standards/Phillips%2066%20JavaScript%20Coding%20Standard.docx?d=w13ff595b078a47bca4db00eed07d381f&csf=1&e=SzX6fp)
* [Phillips 66 SQL Coding Standard](https://phillips66.sharepoint.com/sites/IT_AE66PMO/Digital%20Capability/Shared%20Documents/2.2%20-%20IN%20-%20Business%20Improvement/WS%20-%20DCX/Working%20Documents/10.%20Development%20Standards/Phillips%2066%20SQL%20Coding%20Standard.docx?d=wf8d0654de3f1478ea6bb410a5f3f4515&csf=1&e=tfbVRr)
Developers will follow the appropriate coding standards for the languages being used. Coding standards can be found at

## Unit Tests
Unit tests will be developed for each user story that comply with the [Phillips 66 Automated Unit Testing Guidelines](https://phillips66.sharepoint.com/sites/IT_AE66PMO/Digital%20Capability/Shared%20Documents/2.2%20-%20IN%20-%20Business%20Improvement/WS%20-%20DCX/Working%20Documents/10.%20Development%20Standards/Phillips%2066%20Automated%20Unit%20Testing%20Guidelines.docx?d=w0b8bf2bafdf942f99230863565fe36da&csf=1&e=aHc8nb) and are adequate to test the feature.

All features will be developed in accordance with the DCX architectural guidelines. Specifically, the [Application Stacks (Development Framework)](/Project-Artifacts/Architectural-Overview/Application-Stacks-\(Development-Framework\)) guidelines and the [Backup and DR Strategy](/Project-Artifacts/Architectural-Overview/Backup-and-DR-Strategy).
Unit tests will be developed for each user story that comply with the and are adequate to test the feature.


12 changes: 2 additions & 10 deletions docs/devops-guidelines/DevOps-Guidelines.md
View file
Original file line number Diff line number Diff line change
Expand Up @@ -2,27 +2,19 @@

"DevOps is cultural fusion of People, Process, and Technology to accelerate deliery of Business Value"

![DevOps Continous Improvement](/.images/DevOps.png)
![DevOps Continous Improvement](.images/DevOps.png)

A complete DevOps approach combines critial develop, operations and management concerns so that software projects can continously and consistently deliver high quality solutions.

Each practice within these guidelines works with others to form a working model for continous improvement. In addition, DevOps works hand in hand with portfolio and project management and agile initiatives.

This wiki is intended for the practitioners: team members on projects. It provides a set of guidelines that can be used as a starting point for any project's DevOps implementation. Each project will need to define specific tools and processes that will work best for that project. This wiki can be cloned and used as a starting point for a project specific DevOps Strategy.

For an overview of DevOps, visit the Cloud Runway [DevOps Handbook](https://phillips66.sharepoint.com/sites/IT_DOH).

Topics covered in this site include:
- [Planning and managing work from inception to delivery](/Plan)
- [Source management](/Create)
- [Verifying quality](/Verify)
- [Build and release automation](/Deploy)
- [Monitoring a solution in production](/Monitor)

This site assumes you are using and are familiar with [Azure DevOps](https://dev.azure.com).

## Additional Information

- DevOps Handbook
- Patterns and Templates provided by Cloud Runway
- learning resources
This site assumes you are using and are familiar with [GitHub](https://github.com) or [Azure DevOps](https://dev.azure.com).
23 changes: 8 additions & 15 deletions docs/devops-guidelines/Monitor.md
View file
Original file line number Diff line number Diff line change
Expand Up @@ -7,27 +7,20 @@
|Performance Monitoring|Well established baselines and KPIs that can be tested against, monitored, and improved as a part of CI/CD pipeline and release cycles|AWS CloudWatch, Microsoft SCOM|
|Security Monitoring|Automatically monitor and alert for appropriate credential rotation events, critical vulnerability patches, and user activity anomalies|AWS CloudTrail, SkyHigh, Dome9, QRadar|
|Feedback Management|Build feedback submission tools into user interfaces to obtain feedback directly from customers; leverage Product Owner to translate feedback into feature-oriented user stories to be captured and prioritized by planning tools for future releases|Azure DevOps|
|Consumption Management|Utilize CloudHealth to monitor and report off cloud costs across AWS & Azure; tags applied at resource creation based on ServiceNow application CI|CloudHealth|
|Telemetry|Data is captured for all of the major types of telemetry data, business metrics, application metrics, infrastructure metrics and deployment pipeline metrics. Telemetry data is analyzed and leveraged as KPIs to improve the product as part of the feedback loop.| |
|Consumption Management|Utilize monitoring tools to visualize and report consumption metrics including costs. Use standard resource tags to define and aggregate costs|Azure Monitor, AWS CloudHealth, Splunk, ...|
|Telemetry|Data should be captured for all of the major types of telemetry data, business metrics, application metrics, infrastructure metrics and deployment pipeline metrics. Telemetry data is analyzed and leveraged as KPIs to improve the product as part of the feedback loop.| |

**Performance Monitoring**
- DCX will follow the [guidance from CloudRunway](https://phillips66.sharepoint.com/sites/IT_CloudRunway/DOH/Pages/Monitoring%20and%20Logging.aspx) on monitoring and logging.

- [Amazon CloudWatch Metrics](https://docs.aws.amazon.com/lambda/latest/dg/monitoring-functions.html) will be used to monitor the performance of AWS Lambda functions against expectations.

- [Amazon CloudWatch Metrics](https://docs.aws.amazon.com/AmazonS3/latest/dev/cloudwatch-monitoring.html) will also be used to monitor the performance of AWS S3.

- Other PaaS/SaaS vendors will be monitored using their native tools.

- BloomReach performance monitoring guidelines can be found [here](https://documentation.bloomreach.com/library/concepts/web-application/jmx-management-beans-support.html).
todo

**Security Monitoring**
- DCX will follow the [guidance from CloudRunway](https://phillips66.sharepoint.com/sites/IT_CloudRunway/DOH/Pages/Security.aspx) on security best practices.
todo

**Feedback Management**
-
todo

**Consumption Management**
- DCX will utilize CloudHealth to monitor and report cloud costs across AWS & Azure. Tags will be applied in accordance with the guidance from Cloud Runway.
todo

**Telemetry**
- Telemetry data will be captured [Amazon CloudWatch Metrics](https://docs.aws.amazon.com/AmazonS3/latest/dev/cloudwatch-monitoring.html) and recorded to [Azure Application Insights](https://docs.microsoft.com/en-us/azure/azure-monitor/app/app-insights-overview).
todo

0 comments on commit f069236

Please sign in to comment.