Speed up your work with Alfred 3 Workflows

Make things easy at work. Save time for the important bits. That’s something everyone talks about but there’s no real “that’s mine” guide out there. A while ago I decided to try something new – I switched my entire work place from Linux to macOS. Working with colleagues using their tools on a daily basis made me ask several times – how does that work? How could I use that workflow? Can you show me how the trackpad works? Swiping with two fingers going back in browser history?
Turns out there are a couple of tools which help me save time day by day. Some of them are not part of macOS themselves and thus require you to buy them. If a tool really saves my life (and time) I am willing to do so.
One of these tools is Alfred. Generally speaking Alfred can be used to search your mac, quickly open files and applications, use hotkeys for actions. Things you can achieve with Apple’s Spotlight already. The coolest thing is the additional Alfred Powerpack. This allows you to run shell commands on your macOS. You can extend the functionality by adding custom Alfred workflows. That way you can manage your chat clients, music apps, search the mail application and so on.
Locking your screen requires a somewhat quirky key combination or moving the cursor to hot corners. Both of which I don’t like and therefore just type in “lock” into the Alfred command popup. These days locking my screen is just “Cmd + Space, l, Enter” because Alfred remembers the history. Another tip from Bernd – type “empty” and automatically empty your trash bin.
We’re using Jabber at work, and I’m a heavy Adium user. When I want to chat with a co-worker, I just open Alfred and start typing “im <name>” and a new Adium chat tab opens. This is all thanks to this workflow. If you’re sending an email over the ocean, what time is it? Use this workflow to avoid googling. Another cool tip – if you are for instance converting inches to the metric system, a workflow called units comes in handy.

Yet another workflow is for Github repos which really helps after the migration for all Icinga repositories. Just type in “gh icinga2” and open the corresponding Github repository in your browser. Search for repos or users or open a new issue in a specific repository.

Alfred saves me a lot of time already. Keep focus and develop faster 🙂

Michael Friedrich
Michael Friedrich
Senior Developer

Michael ist seit vielen Jahren Icinga-Entwickler und hat sich Ende 2012 in das Abenteuer NETWAYS gewagt. Ein Umzug von Wien nach Nürnberg mit der Vorliebe, österreichische Köstlichkeiten zu importieren - so mancher Kollege verzweifelt an den süchtig machenden Dragee-Keksi und der Linzer Torte. Oder schlicht am österreichischen Dialekt der gerne mit Thomas im Büro intensiviert wird ("Jo eh."). Wenn sich Michael mal nicht in der Community helfend meldet, arbeitet er am nächsten LEGO-Projekt oder geniesst...

Benutzung von Git zur Environment-Verwaltung bei Puppet mit r10k

Puppet_LogoNachdem ich nun schon jahrelang mit Git im Puppetumfeld kämpfe, gibt es nun mit dem Ruby-Skript r10k eine wunderbar nützliche Ergänzung. Mit r10k wird das Deployment von Branches als dynamische Environments zum Kinderspiel. Stellt sich natürlich zuerst die Frage, was versteht man unter dynamischen Environments?
Gemeint ist das Hinzufügen bzw. Löschen von Environments zur Laufzeit. Nur wozu das Ganze? Wenn ich z.B. an einem Puppetmodul arbeite will ich es nicht nur lokal mit puppet apply testen, sondern auch mit einem Puppetmaster. Dieses vorgehen wird spätestens zum Muss, wenn ich Exported Resources verwende möchte.
Genug der reinen Worten, ein skizziertes Beispiel wird es verdeutlichen. Wir starten mit der Konfiguration von Puppet für die Verwendung dynamischer Environments, hierzu passen wir die puppet.conf auf unserem Master an.

[main]
modulepath=/etc/puppet/environments/$environment/modules

71px-Git-logo.svgDas Verzeichnis /etc/puppet/environments muss vorhanden sein, die untergeordneten werden von r10k automatisch nach Bedarf angelegt. Nun benötigen wir ein GIT-Repository, aus dem r10k jeden Branch in ein Environment umwandelt. Das r10k-site.git genannte Repository erzeugen wir als Remote-Repository auf unserem Puppetmaster.

# git init --bare r10k-site.git

Bevor wir dieses mit Inhalt befüllen, ist r10k noch zu installieren

# gem install r10k

und zu konfigurieren. Letzteres ist in der Datei /etc/r10k.yaml vorzunehmen.

:cachedir: /var/cache/r10k
:sources:
  puppet:
    remote: "/var/repositories/r10k-site.git"
    basedir: /etc/puppet/environments
:purgedirs:
  - /etc/puppet/environments

Neben einem Cache-Verzeichnis, wird hier mit remote das Remote-Repository angegeben und das Verzeichnis, in das wir jeden Branch als Environment bauen lassen möchten. Mit purgedirs sorgen wir dafür, dass gelöschte Branche auch als Environment wieder entfernt werden.
Nun wählen wir uns einen Ort für ein git clone von r10k-site.git aus. In diesem legen wir dann die gewünschten Branches an, die dann zu den von uns gewünschten Environments zusammen gebaut werden. Jeder Branch muss hierbei eine Datei Puppetfile enthalten, in der wir, die in diesem Environment einzubauenden Module angeben.

forge "http://forge.puppetlabs.com"
mod "puppetlabs/stdlib", "3.2.2"
mod "tomcat",
  :git => "git@github.com:lbetz/puppet-tomcat.git",
  :ref => "0.3.2"

Ruft man nun das Ruby-Skript auf unserem Host auf dem r10k konfiguriert ist, z.B. mit

# r10k deploy environment -p

auf, werden alle Branches mit den in Puppetfile angegebenen Modulen als eigenes Environment nach basedir geschrieben. Die Option -p sorgt jeweils für erforderliche Updates der Module. Ein bestimmtes Environment kann mit

# r10k deploy environment <env_name> -p

erstellt werden. Packt man diese Aufrufe in einen Git-Hook, z.B. post-update, werden die Environments bei jedem Update des Repositories automatisch aktualisiert, angelegt oder gelöscht.

Lennart Betz
Lennart Betz
Senior Consultant

Der diplomierte Mathematiker arbeitet bei NETWAYS im Bereich Consulting und bereichert seine Kunden mit seinem Wissen zu Icinga, Nagios und anderen Open Source Administrationstools. Im Büro erleuchtet Lennart seine Kollegen mit fundierten geschichtlichen Vorträgen die seinesgleichen suchen.

Git Branching mit dem richtigen flow

Git arbeitet mit Branches fast mühelos – Operationen wie checkout und merge werden nahezu verzugslos ausgeführt und durch den 3-Wege-‘merge’, ist häufiges Zusammenführen von Branches, auch über einen längeren Zeitraum, einfach zu bewerkstelligen. Das macht es komfortabel, Workflows zu etablieren, die einem bei der Entwicklung unterstützen.
Auf der NETWAYS Development-Klausur im Februar 2013, haben wir uns dazu entschieden, dem von Vincent Driessen im Jahr 2010 vorgestellten Branching-Modell zu folgen. Für die Umsetzung dieses Modells stellt er Git-Erweiterung, names git-flow bereit.
Dieser Workflow verfolgt den Ansatz, im master-Branch nur Code zu halten, der entweder released wurde oder production ready ist. Parallel dazu, gibt es einen Branch zum Arbeiten, der alle abgeschlossenen Änderungen für das nächste Release enthält. Vincent nennt diesen Zweig develop, wir next. Von diesem Branch würden Nightly Builds erstellt werden. Sobald dieser parallele Zweig einen stabilen Status erreicht, wird er mit dem master zusammengeführt. Erinnern wir uns, dass der master nur Code hält, der released wurde, so wird jedes mal, wenn Änderungen in den master übernommen werden, eine neue Version der Software veröffentlicht.
Neben diesen langfristigen Branches mit unbegrenzter Lebensdauer, werden eine Vielzahl von anderen Zweigen eingesetzt, die paralleles und themenbezogenes Arbeiten, Release-Vorbereitung und Fehlerbehebung von bereits veröffentlichen Versionen erleichtern. Dabei gelten strikte Regeln, bezüglich Namensgebung und von welchem Branch sie sich abzweigen und mit welchem sie zusammengeführt werden. Feature- oder Topic-, Release- und Hotfix-Branches haben eine begrenze Lebensdauer, da sie schlussendlich gelöscht werden.
git-flow_branching
Feature-Branches
In Feature- oder Topic-Branches werden neue Features für zukünftige Releases entwickelt. Welches Release das Feature enthält, muss zum Zeitpunkt der Entwicklung nicht bekannt sein. Der Feature-Branch existiert nur solange, wie das Feature in Entwicklung ist, d.h. bis es zusammengeführt oder verworfen wird. Natürlich können und sollen mehrere Features parallel entwickelt werden.
Ein neuer Feature-Branch zweigt sich vom next ab:

git checkout -b feature/scheduler next

Vorausgesetzt das Feature wird nicht verworfen, wird es für das nächste Release mit next zusammengeführt:

git checkout next
git merge --no-ff feature/scheduler
git branch -d feature/scheduler
git push origin next

Der –no-ff-Schalter (no fast forward) ist ganz wichtig und bewirkt, dass bei einem merge, immer ein neuer commit erzeugt wird. Dadurch geht die historische Existenz eines Feature-Branch nicht verloren und es ist leichter nachzuvollziehen welche commits zu welchem Feature gehör(t)en.
Release-Branches
Release-Branches unterstützen die Vorbereitung eines neuen Release. Ein Release-Branch wird erstellt, wenn next dem gewünschten Zustand des nächsten Release entspricht. Das ist z.B. ab dem Beginn der Testphase oder dem Zeitpunkt des Code-Freeze.
Ab jetzt landen nur noch Bugfixes und Änderungen an Metadaten im Branch. Ein commit der immer gemacht wird, ist die Änderung der Versionsnummer.
Alle Features, die mit in das Release sollen, müssen mit next zusammengeführt worden sein. Features für zukünftige Releases, sind noch nicht im next.
Der Release-Branch zweigt sich vom next ab:

git checkout -b release/1.0 next

Wenn der Branch bereit für ein Release ist, wird er mit dem master zusammengeführt und mit einem tag versehen. Damit in zukünftigen Releases, die hier eingeflossenen Bugfixes nicht fehlen, werden die Änderungen auch in next übernommen:

git checkout master
git merge --no-ff release/1.0
git tag -a 1.0
git checkout next
git merge --no-ff release/1.0
git branch -d release/1.0
git checkout master
git push origin master
git push --tags

Hotfix-Branches
Hotfix-Branches verhalten sich im Grunde wie Release-Branches, allerdings sind diese natürlich ungeplant. Ist das letzte Release fehlerhaft, wird eine neue bereinigte Version der Software veröffentlicht.
Der Hotfix-Branch zweigt sich vom master ab:

git checkout -b hotfix/1.0.1 master

Der oder die Fehler werden jetzt in einem oder mehreren commits behoben. Die Änderung der Versionsnummer darf hier nicht vergessen werden. Wenn der Branch bereit für ein Release ist, wird er mit dem master zusammengeführt und mit einem tag versehen. Damit in zukünftigen Releases, die hier eingeflossenen Bugfixes nicht fehlen, werden die Änderungen auch in next übernommen:

git checkout master
git merge --no-ff hotfix/1.0.1
git tag -a 1.0.1
git checkout next
git merge --no-ff hotfix/1.0.1
git branch -d hotfix/1.0.1
git checkout master
git push origin master
git push --tags

Und wo bleibt der flow?
Alle genannten Operationen werden von den Git-Erweiterungen git-flow bereitgestellt. Um git-flow zu verwenden, muss das repository entsprechend initialisiert werden:

git flow init

Die Operationen für ein neues Release sind mit git-flow deutlich übersichtlicher:

git flow release start 1.0
...
git flow release finish 1.0

Die Befehle für Feature- und Hotfix-Branches sind ähnlich. Nachlesen kann man sie hier. Bis jetzt fahren wir damit ganz gut ;-).
(Bildquelle: entwickler.com)

Eric Lippmann
Eric Lippmann
Lead Senior Developer

Eric kam während seines ersten Lehrjahres zu NETWAYS und hat seine Ausbildung bereits 2011 sehr erfolgreich abgeschlossen. Seit Beginn arbeitet er in der Softwareentwicklung und dort an den unterschiedlichen NETWAYS Open Source Lösungen, insbesondere inGraph und im Icinga Team an Icinga Web. Darüber hinaus zeichnet er sich für viele Kundenentwicklungen in der Finanz- und Automobilbranche verantwortlich.