developermetrics / devopsmetrics Goto Github PK

Vertical: Show all settings for a single metric (current implementation)
Horizontal: for a setting, show all of the metrics

Daily DevOps Metrics

Days Included In Metrics : 30

Build History

• Create new marketplace publisher and destination
• Create hello world app
• Package hello world app
• Publish hello world app
• Use CI to package package
• Use CD to publish package
• Implement deployment frequency

• Add ARM template
• Add slots to web app
• Add functional testing via Selenium to test the staging slot before it swaps
• Add code reviews to branch policies
• Create architecture diagram

Example: https://devopsmetrics-prod-eu-web.azurewebsites.net/Home/Project?rowKey=samsmithnz_DevOpsMetrics_DevOpsMetrics%20CI%2FCD

• Many of the build pipelines remove builds after a certain number of builds or days, especially Pull Request/feature branches

By caching the data, I'll have a longer list of data to build a real picture.

• Add builds, pull requests and pull request commits to an Azure Storage table
• Create a process to update these tables regularly (hourly? daily?)
• Move the criteria into a settings table
• Final integration testing

https://docs.microsoft.com/en-us/azure/cosmos-db/import-data

Daily DevOps Metrics

Days Included In Metrics : 30

Build History

Daily DevOps Metrics

Days Included In Metrics : 30

Build History

Daily DevOps Metrics

Days Included In Metrics : 30

Build History

Probot needs to do

• Create prototype Probot
• Run periodically
• Run the API to get data
• Process the data and create a static image from the binary stream
• Fix the settings
  Stretch goals:
• stretch goal: Post the badges for all 4 metrics
• stretch goal: Post the badges into readme.md file
• stretch goal: Can we post as the bot instead of the owner

Daily DevOps Metrics

Days Included In Metrics : 30

Build History

Daily DevOps Metrics

Days Included In Metrics : 30

Build History

I suspect the function that is part of the action groups has stopped. Need to build in some redundancy.

While all secrets in the POC are managed with User Secrets and injecting secrets into the web app on deployment, there could be some benefit to refactoring PAT Token and Client Secrets into a key vault.

Daily DevOps Metrics

Days Included In Metrics : 30

Build History

Currently we only support multi-stage builds

When it's less than 1, it can't be "per day". That doesn't make sense. It should be per week (1/7), and per month (1/30).

Daily DevOps Metrics

Days Included In Metrics : 30

Build History

From a scale perspective, this is just one table storage container, can it handle 10, 100, 1000 users? We certainly don't want to be managing other users data.

Therefore, from a data perspective, users need confidence that their data is protected - hence, the current solution with a central azure data store is not ideal. There should be some way for users to easily configure and deploy this to their own tenants.

Daily DevOps Metrics

Days Included In Metrics : 30

Build History

Daily DevOps Metrics

Days Included In Metrics : 30

Build History

Have a page with UI controls

• A dropdown with all of the settings
• A dropdown, where select a percentage (0,10,25,50,75,100), which we will apply the filter to every % item (take the total number, and then update each nth item)
• A button to apply the changes.

Daily DevOps Metrics

Days Included In Metrics : 30

Build History

They should be the same (for example SamLearnsAzure)

1. "Why are we here and what problem are we solving"
2. "What we produced..."

Couple options here:

• Put the pat tokens into a key vault

• Use database/settings table with key to identify it
  exchange with a code that extracts the PAT token from the settings table (and therefore isn't passed around like candy).

• Basic Authentication:
  Advantages:

  • PAT tokens and Client Secrets are visible in the URL

  Disadvantages:

  • Basic authentication is still user visible in requests. This is better, but not the best.

• Other...?

Is this too many options?

7 days, 14 days, 21 days, 30 days, 60 days, 90 days

• Have a summary page
• Have individual detailed pages

Example: https://devopsmetrics-prod-eu-web.azurewebsites.net/Home/Project?rowKey=samsmithnz_DevOpsMetrics_DevOpsMetrics%20CI%2FCD

Should it be a GitHub app or oAuth app?

• Make decision on GitHub app or oAuth app? (GitHub App)

https://docs.github.com/en/developers/apps/about-apps
https://docs.github.com/en/developers/apps/differences-between-github-apps-and-oauth-apps

• GitHub apps run as the user who authorized them. GitHub Apps run as themselves.

• Establish language needed
• Create base GitHub app and setup (probably storage account connection string?)
• Add CI/CD to continuously push changes
• Add deployment frequency metric to GitHub app
• Review