All Projects → guardian → Prout

guardian / Prout

Licence: apache-2.0
Looks after your pull requests, tells you when they're live

Programming Languages

scala
5932 projects

Projects that are alternatives of or similar to Prout

Devops Readme.md
What to Read to Learn More About DevOps
Stars: ✭ 398 (+188.41%)
Mutual labels:  monitoring, continuous-deployment
Flux
Successor: https://github.com/fluxcd/flux2 — The GitOps Kubernetes operator
Stars: ✭ 6,688 (+4746.38%)
Mutual labels:  monitoring, continuous-deployment
Cimonitor
Displays CI statuses on a dashboard and triggers fun modules representing the status!
Stars: ✭ 34 (-75.36%)
Mutual labels:  monitoring, continuous-deployment
Pg Monitor
💻 Events monitor for pg-promise
Stars: ✭ 132 (-4.35%)
Mutual labels:  monitoring
Git Pull Request
git command to automatically pull github pull requests into their own branch
Stars: ✭ 132 (-4.35%)
Mutual labels:  pull-requests
Lighthouse Monitor
Investigate performance over your whole company with lighthouse
Stars: ✭ 136 (-1.45%)
Mutual labels:  monitoring
Nvidia gpu prometheus exporter
NVIDIA GPU Prometheus Exporter
Stars: ✭ 138 (+0%)
Mutual labels:  monitoring
Devtron
Software Delivery Workflow For Kubernetes
Stars: ✭ 130 (-5.8%)
Mutual labels:  continuous-deployment
Raven Python
Raven is the legacy Python client for Sentry (getsentry.com) — replaced by sentry-python
Stars: ✭ 1,677 (+1115.22%)
Mutual labels:  monitoring
Kubebox
⎈❏ Terminal and Web console for Kubernetes
Stars: ✭ 1,855 (+1244.2%)
Mutual labels:  monitoring
Build
Netlify Build runs the build command, Build Plugins and bundles Netlify Functions.
Stars: ✭ 135 (-2.17%)
Mutual labels:  continuous-deployment
Inertia
✈️ Effortless, self-hosted continuous deployment for small teams and projects
Stars: ✭ 133 (-3.62%)
Mutual labels:  continuous-deployment
Inspectit Ocelot
inspectIT Ocelot - Java agent for collecting application performance, tracing and behavior data
Stars: ✭ 135 (-2.17%)
Mutual labels:  monitoring
Websiteone
A website for Agile Ventures
Stars: ✭ 132 (-4.35%)
Mutual labels:  continuous-deployment
Scout apm ruby
ScoutAPM Ruby Agent. Supports Rails, Sinatra, Grape, Rack, and many other frameworks
Stars: ✭ 137 (-0.72%)
Mutual labels:  monitoring
Alerting Kibana Plugin
📟 Open Distro for Elasticsearch Kibana Alerting Plugin
Stars: ✭ 131 (-5.07%)
Mutual labels:  monitoring
Nexus433
433MHz temperature and humidity sensor receiver that integrates with home automation systems.
Stars: ✭ 137 (-0.72%)
Mutual labels:  monitoring
Lindb
LinDB is a scalable, high performance, high availability distributed time series database.
Stars: ✭ 2,105 (+1425.36%)
Mutual labels:  monitoring
Go Sysinfo
go-sysinfo is a library for collecting system information.
Stars: ✭ 133 (-3.62%)
Mutual labels:  monitoring
Monitaure
🔔 A server uptime monitoring progressive web application - NO LONGER MAINTAINED
Stars: ✭ 135 (-2.17%)
Mutual labels:  monitoring

Prout

"Has your pull request been deployed yet?" - Guardian blogpost

Tells you when your pull-requests are live. Tells you when they're not, and should be.

prout overduethenseen

Prout comes from the tenet that:

Developers are responsible for checking their changes on Production

This becomes more important, and easier once you move to a Continuous Deployment release process. Important, because now a developer can break the site simply by hitting 'Merge' on a pull request - but also easier because with such a small delay (say, less than 10 minutes) between merging the work and having it ready to view in a Production setting, the developer is in a much better place to review their work; it's still fresh in their mind.

While everyone on your team may agree with this philosophy, that 10 minute lag between merge and deploy can be enough time for a developer like me to get distracted ("Look, shiny thing!" or, more realistically, "What's the next bit of work?") and forget about promptly reviewing their changes on Production.

Prout simply notifies developers in their pull request that the code has been seen in Production (a slightly stronger statement than simply saying it's been deployed).

Configuration

Follow the 4-step program:

  1. Give prout-bot write-access to your repo (so it can set labels on your pull request)
  2. Add one or more .prout.json config files to your project
  3. Add callbacks to prout - ie a GitHub webhook and ideally also a post-deploy hook
  4. Expose the commit id of your build on your deployed site

Add config file

Add a .prout.json file to any folder you want monitored in your repo:

{
  "checkpoints": {
    "DEV": { "url": "http://dev.mysite.com/", "overdue": "10M" },
    "PROD": { "url": "http://mysite.com/", "overdue": "1H" }
  }
}

When a pull-request changes a file anywhere under that folder, Prout will scan the checkpoints defined in your config file, and update the pull-request with labels and a comment as appropriate. The url you specify in the checkpoint will be fetched, and the contents of the response will be read- so long as you embed the commit id that response, Prout will be able to work out whether or not the PR has been deployed.

Add callbacks

Add Prout-hitting callbacks to GitHub and (optionally) post-deploy hooks to your deployment systems so that Prout can immediately check your site.

GitHub

Add a GitHub webhook with these settings:

  • Payload URL : https://prout-bot.herokuapp.com/api/hooks/github
  • Content type : application/json

The hook should be set to activate on Pull Request events.

Post-deploy hooks

Whatever deployment tool you use (RiffRaff, Heroku, etc) just set it to hit Prout as a post-deploy hook (for your repo on github.com/[owner]/[repo]):

https://prout-bot.herokuapp.com/api/update/[owner]/[repo]

Hitting that url (GET or POST) will always prompt Prout to scan the repository for outstanding pull-requests.

Expose the commit id

You must embed the commit id in your site - we do this on membership.theguardian.com for instance.

I use the sbt-buildinfo plugin to store the Git commit id in my stored artifact, and then expose that value on the production site. The ugly-looking SBT config is:

buildInfoKeys := Seq[BuildInfoKey](
      name,
      BuildInfoKey.constant("gitCommitId", Option(System.getenv("BUILD_VCS_NUMBER")) getOrElse(try {
        "git rev-parse HEAD".!!.trim
      } catch {
          case e: Exception => "unknown"
      }))
    )

Slack

Users can configure a Slack hook for Prout by creating a new Slack 'Incoming Webhook':

https://your-domain.slack.com/services/new/incoming-webhook

...this will get you a 'Webhook URL', which looks something like this:

https://hooks.slack.com/services/T05FTQF9H/B012N1Y2Y/p9VyRC1ZlTqNGuu

...stick that url into a GitHub webhook for your repo as the 'Payload URL':

https://github.com/my-org/my-repo/settings/hooks/new

...and then (optionally) disable the hook in GitHub! You don't actually want to send GitHub events to the hook - this is just a place to store the private url where Prout can find it. Note that Prout needs repo-admin access in order to read the hook data!

Status

Prout has a status page per repository available at https://prout-bot.herokuapp.com/view/{organisation}/{repository}. This lists useful information like if it was able to find .prout.json, which commit it thinks is currently deployed in production, etc.

Prout also logs lots of useful information which is available in the heroku backend.

Run your own instance of Prout

Deploy

...you want to run your own instance of Prout - the instance at https://prout-bot.herokuapp.com/ is really only for the Guardian.

Note that the project description data, including the texts, logos, images, and/or trademarks, for each open source project belongs to its rightful owner. If you wish to add or remove any projects, please contact us at [email protected].