Seite wählen

NETWAYS Blog

Virtuelle Entwicklungsumgebungen mit Vagrant

von | Jun 27, 2013 | , , , , ,

Mit Vagrant beschreibt und erstellt man virtuelle Entwicklungsumgebungen, was Entwicklern das Leben deutlich vereinfacht. Es läuft unter Linux, Windows und Mac OS X. Wenige Handgriffe reichen, um eine virtuelle Maschine in Betrieb zu nehmen und einzurichten.
Die Umgebung wird über ein Vagrantfile konfiguriert, welches u.a. port forwarding, mounts, Netzwerkkonfiguration und automatische Installation von Software steuert. Letzteres ist über Shellskripte, Ansible, Chef oder Puppet möglich.
Vagrant kann out of the box mit VirtualBox verwendet werden. VMWare ist auch möglich, aber kostenpflichtig. Weitere provider wie lxc findet man auf github.
Warum Vagrant?
Hauptgrund ist die klar definierte Umgebung. Jeder arbeitet mit den exakt gleichen Bibliotheken und identischen Versionen von Software. Infrastrukturkomponenten müssen nicht lokal installiert werden und die Umgebung ist reproduzierbar.
Zum Weiterlesen empfehle ich die Anleitung für Einsteiger.

Eric Lippmann
Eric Lippmann
CTO
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 für viele Kundenentwicklungen in der Finanz- und Automobilbranche verantwortlich.
Lies mehr von Eric und triff unser Team

inGraph 1.0.2 released

von | Mai 21, 2013 | , , , ,

inGraph - LogoDie neue stabile Version 1.0.2 unseres Graphing-Tools kann ab sofort unter www.netways.org heruntergeladen werden.
Folgende wichtige Fehlerbehungen sind im Release enthalten:

  • Stark verbesserte Performance mit PostgreSQL.
  • Behebt Kompatibilitätsprobleme mit SQLAlchemy Versionen größer 0.8.
  • Behebt Probleme mit fehlerhaften Performancedaten.
  • Aktiviert logging nach /var/log/ingraph, konfigurierbar mit –with-log-dir-Switch.

Ausführlichere Informationen zu den behobenen Problemen sind unter www.netways.org zu finden. Dokumentation zum Projekt befindet sich im Wiki.

Eric Lippmann
Eric Lippmann
CTO
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 für viele Kundenentwicklungen in der Finanz- und Automobilbranche verantwortlich.
Lies mehr von Eric und triff unser Team

PostgreSQL bulk inserts mit Python

von | Mai 16, 2013 | ,

Wer oft viele Daten in seine PostgreSQL Datenbank schreibt, dem möchte ich den COPY-Befehl ans Herz legen. Damit können Daten zwischen Dateien und Tabellen kopiert werden. Mit Psycopg2, „dem“ PostgreSQL-Datenbankadapter für Python, sieht das dann ungefähr so aus:

import psycopg2
from cStringIO import StringIO
from itertools import imap
rows = [
    # Wert Spalte A, Wert Spalte B
    [1, 1],
    [2, 2],
    [3, None]
    # ...
]
buff = StringIO()
for row in rows:
    # \t ist standardmäßig der Spaltentrenner und join erwartet string
    print >>buff, "\t".join(imap(str, row))
# Nicht vergessen 😉
buff.seek(0)
with psycopg2.connect('...') as conn:
    with conn.cursor() as cursor:
        # None als NULL senden
        cursor.copy_from(buff, 'Tabelle', null='None')

Dass das ganze echt schnell ist, muss mir an dieser Stelle einfach geglaubt werden ;-).

Eric Lippmann
Eric Lippmann
CTO
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 für viele Kundenentwicklungen in der Finanz- und Automobilbranche verantwortlich.
Lies mehr von Eric und triff unser Team

Git Branching mit dem richtigen flow

von | Apr 4, 2013 | , ,

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
CTO
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 für viele Kundenentwicklungen in der Finanz- und Automobilbranche verantwortlich.
Lies mehr von Eric und triff unser Team

NETWAYS-Development-Klausur 2013

von | Feb 21, 2013 | ,

Heute früh Punkt 7:00 Uhr machte sich das NETWAYS Development Team, sechs an der Zahl, auf in die Gemeinde Rimbach um für zwei Tage, in entspannter Atmosphäre, die Dinge zu besprechen, die im Büroalltag zu kurz kommen.
Um Projekte möglichst erfolgreich abzuschließen, neuen Mitarbeitern den Einstieg zu erleichtern oder die Arbeit im Team zu verbessern, sind Standards und definierte Prozesse essenziell. Bei der Dev-Klausur im letzten Jahr haben wir uns beispielweise dazu entschieden, einem Scrum-ähnlichen Entwicklungsprozess zu folgen.
Wichtige Themen dieses Jahr sollen sein, wie und in welchem Format wir dokumentieren, welchem Git branching-Modell wir folgen und allgemeine Diskussion über neue/veraltete Technologien.
Am Abend werden in gemütlicher Runde, natürlich auch nicht berufliche Themen besprochen ;-).
Abschließend ein paar Bilder:

Eric Lippmann
Eric Lippmann
CTO
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 für viele Kundenentwicklungen in der Finanz- und Automobilbranche verantwortlich.
Lies mehr von Eric und triff unser Team

Trainings

Web Services

Events