In Zeiten von Teams, Slack, Rocket Chat, Zoom & Co. sollte man meinen, dass ein vorsintflutlicher Kommunikationskanal längst ausgestorben ist: die E-Mail.
Doch dem ist nicht so – im Gegenteil: Während wir im alltäglichen Projektgeschäft eher selten auf E-Mails zurückgreifen, erfreuen sie sich allergrößter Beliebtheit bei den Tools und Systemen, mit denen wir jeden Tag arbeiten, gern auch im Kontext gleich mehrerer Projekte:
- “One of your dependencies has a security vulnerability” (GitHub)
- “<hier Lieblingsteampartner/in einfügen> requested changes on this pull request” (GitHub)
- “<hier Lieblingsteampartner/in einfügen> requested your review” (GitHub)
- “<hier Lieblingsteampartner/in einfügen> commented on this pull request” (GitHub)
- “<hier Lieblingsteampartner/in einfügen> pushed 42 commits” (GitHub)
- “<hier Lieblingsteampartner/in einfügen> commented on <ticket>” (Jira)
- “<hier Lieblingsteampartner/in einfügen> assigned <ticket>” (Jira)
- “<hier Lieblingsteampartner/in einfügen> mentioned you on a page” (Confluence)
- “Build succeeded” (Azure DevOps)
- “Azure DevOps personal access token nearing expiration” (Azure DevOps)
- “FAILED” (Jenkins)
- “Your Azure API Management instance is ready” (Azure)
- “Great job! <hier Lieblingskollegin einfügen> has approved your Tempo Timesheet” (Tempo)
- …
Wir stellen fest: Ein wesentlicher Teil automatischer “Kommunikation” steht in direktem Zusammenhang mit den Dingen, an denen wir arbeiten und – noch viel wichtiger – den Menschen, mit denen wir zusammenarbeiten.
Und wir stellen auch fest: Wer viel arbeitet, bekommt viele E-Mails. Da sie in irgendeiner Form mit den Inhalten unserer Arbeit und den Menschen um uns zu tun haben, sind sie natürlich auch auf die eine oder andere Weise wichtig und relevant. Dennoch haben sie eine Gemeinsamkeit: Sie überfluten den Posteingang und die wirklich wichtigen, von Menschen geschriebenen E-Mails können dann durchaus schon mal untergehen – und wir selbst drohen zu ertrinken.
Dabei hatten wir nur die besten Absichten: Die Verwendung der Tools und die nachvollziehbare Kommunikation darüber ist genauso eine bewusste Entscheidung. Wir haben uns bewusst dagegen entschieden, alle automatischen Benachrichtigungen zu deaktivieren, damit wir mitbekommen, wenn jemand zum Beispiel ein Review von uns haben möchte oder auf irgendeine Antwort von uns wartet. Wer braucht schon gern eine Extra-Einladung?
Die Folge ist nur eben leider, dass der Posteingang überquillt. Wer kennt es nicht?
Zum Glück gibt es eine Lösung: Regeln. Sie werden auf eingehende E-Mails angewendet und entsprechend markiert, sortiert, (gelöscht) usw. Jeder kennt sie, vermutlich jeder nutzt sie. Wären sie doch nur nicht so umständlich zu konfigurieren, vor allem wenn es immer wieder dieselben Arten von E-Mails sind, die bearbeitet werden wollen …
Als ich also kürzlich mal wieder mit dem Vorsatz, meinen Posteingang aufzuräumen und der Flut Herr zu werden, in einer ruhigen Minute vorm Bildschirm saß und schon nach der zweiten, neu angelegten Regel eigentlich keine Lust mehr hatte, kam mir ein Gedanke:
Wir verbringen einen Großteil unserer Zeit mit Kapuzenpullover und Sonnenbrille am Laptop. Auf der Kommandozeile rauschen Buchstaben- und Zahlenreihen vorbei. Das ist unser liebstes Umfeld. In unseren Projekten verwenden wir so einiges an Zeit darauf, möglichst viel in Code auszudrücken, wiederzuverwenden und zu automatisieren. Dabei ist es ziemlich egal, ob es um Build-Pipelines, Cloud-Infrastruktur, Monitoring-Dashboards oder das Generieren von Konfigurations-Dateien geht. Terraform ist sofort zur Stelle!
Da muss es doch auch was für das leidige Thema Regeln in Outlook geben!
Gibt es!
Ich bin ja fest davon überzeugt, dass der Microsoft-Angestellte und GitHub-Nutzer magodo genauso genervt war wie ich. Oder er ist einfach nur Nerd durch und durch. Auf jeden Fall hat er mit einem kleinen Freizeitprojekt mein Problem gelöst: Er schrieb einen Terraform-Provider für Outlook. Der Provider kennt genau drei Ressourcen: Ordner, Kategorien und Regeln – die Sandsäcke für den Flutschutz im Posteingang, nicht mehr und nicht weniger!
Da der Outlook-Provider die Microsoft Graph API mittels OAuth Authorization Code Flow nutzt, ist die einzige Voraussetzung für seinen Einsatz eine App-Registrierung in Azure Active Directory. Sobald man darüber seine Client Credentials bekommen hat, kann man mit der Outlook-Automatisierung loslegen!
In der main.tf des Terraform-Scripts wird der Provider ganz einfach mit den Credentials konfiguriert, zum Beispiel:
terraform {
required_providers {
outlook = {
source = "magodo/outlook"
version = ">=0.0.4"
}
}
}
provider "outlook" {
auth_method = "auth_code_flow"
client_id = var.az_client_id
client_secret = var.az_client_secret
}
Da ich meine bevorzugte Ordnerstruktur in Outlook bereits habe, entschied ich mich dazu, die vorhandenen Ordner einzubinden, ohne sie mit Terraform zu managen.
Zunächst benötige ich den Posteingang als Einstiegspunkt:
data "outlook_mail_folder" "inbox" {
well_known_name = "inbox"
}
Danach kann ich beliebige Ordner auf der ersten Ebene einbinden:
locals {
folders = {
proj1 = {
name = "Project 1"
{
pentacor = {
name = "pentacor"
}
}
}data "outlook_mail_folder" "folder" {
for_each = local.folders
parent_folder_id = data.outlook_mail_folder.inbox.id
name = each.value.name
}
Wenn ich dann für die einzelnen Regeln einen Ordner brauche, kann ich sie über data.outlook_mail_folder.inbox oder data.outlook_mail_folder.folder[parent_folder_key] referenzieren. Ähnlich funktioniert es auch mit Kategorien.
Mit Ordnern und Kategorien habe ich nun alle Voraussetzungen, um tatsächlich meine Regeln als Terraform-Ressourcen zu definieren:
resource "outlook_message_rule" "example" {
name = "move message from foo@bar.com to Foo"
enabled = true
condition {
from_addresses = ["foo@bar.com"]
}
action {
move_to_folder = outlook_mail_folder.example.id
}
}
Mittels Variablen und Schleifen, sowie der einen oder anderen Bedingung, kann ich nun auf einfache Weise reproduzierbar und wiederverwendbar Regeln in Outlook anlegen.
Zum Beispiel besteht meine Konfiguration für die Regeln von verschiedenen Projekten lediglich aus diesen Parametern:
- Projekt-Key von Jira
- Key des in Terraform eingebundenen Überordners (beispielsweise
proj1)
- Namen von Unterordnern, die ich nutzen möchte (
["Build", "Confluence", "Git", "Jira"])
- Absender-Adresse von GitHub
- Name der GitHub-Organisation
- Name des Confluence-Spaces
Damit bin ich nur noch vier einfache Schritte von einem gut sortierten Posteingang entfernt, zwischenzeitlich muss ich mich lediglich mit meinem Microsoft-365-Account anmelden:
1. terraform init2. terraform validate3. terraform plan -parallelism=14. terraform apply -parallelism=1
Die Microsoft-API mag übrigens parallele Aufrufe nicht so gern. Terraform könnte vieles parallel machen, das führt jedoch zu Fehlern wie 429 Too many requests. Da wir es uns aber durch das Skript schon so gemütlich gemacht haben, gönnen wir uns einfach die Entschleunigung durch -parallelism=1. Ein API-Request zur gleichen Zeit ist auch okay. Und wenn es uns doch einmal zu lange dauert, bestellen wir uns einfach eine Pizza, denn auch das geht ja mit Terraform, dank des Providers für Domino’s Pizza.
