Unser Ziel ist die Auslieferung von qualitativ hochwertiger Software in kurzen Zyklen. Dafür wird die Software iterativ und inkrementell in enger Zusammenarbeit mit den Usern entwickelt. Für die Planung, die Tests und Umsetzung von Änderungen an der produktiven IT-Umgebung verwenden wir standardisierte Verfahren. So können wir das Risiko von negativen Auswirkungen auf Systeme, welche in produktivem Betrieb stehen, minimieren.

«DevOps» und «Infrastructure as Code»

seantis lebt eine «DevOps» Kultur und das «Infrastructure as Code» Paradigma. Bei DevOps arbeiten die für Entwicklung und Betrieb verantwortlichen Teams zusammen, um Anwendungen schnell, in hoher Qualität und kontrolliert zu erstellen, zu testen, bereitzustellen und zu überwachen. Die Trennung zwischen IT-Betrieb und Entwicklung wird bewusst aufgehoben.

Firmen wie Netflix setzen sehr bewusst auf «DevOps». In seinem Blog schreibt das Team von Netflix davon, wie das Team, welches den «Schmerz» des Betriebs spürt, besser darauf reagieren kann. Das Team, welches die Software entwickelt, soll auch für deren Betrieb zuständig sein.

“Operate what you build” puts the devops principles in action by having the team that develops a system also be responsible for operating and supporting that system. Distributing this responsibility to each development team, rather than externalizing it, creates direct feedback loops and aligns incentives. Teams that feel operational pain are empowered to remediate the pain by changing their system design or code; they are responsible and accountable for both functions. Each development team owns deployment issues, performance bugs, capacity planning, alerting gaps, partner support, and so on.

Gemäss dem «Infrastructure as Code» Paradigma wird die Infrastruktur durch Code – und nicht durch manuelle Prozesse – verwaltet und bereitgestellt. Es werden Konfigurationsdateien erstellt, welche die komplette Spezifikation der Infrastruktur exakt vorgeben. So ist sichergestellt, dass immer genau die gleiche Umgebung provisioniert wird und die Infrastruktur so homogen wie möglich bleibt. Ebenso werden undokumentierte und damit problematische Ad-hoc-Änderungen der Konfiguration vermieden.

Zielsetzungen «Infrastructure as Code»

Gemäss dem «Infrastructure as Code» (Morris 2016) Paradigma verfolgen wir folgende Ziele:

  • Die IT-Infrastruktur unterstützt und macht Änderungen möglich, anstatt ein Hindernis oder eine Beschränkung zu sein.
  • Veränderungen werden zur Routine, ohne Drama und Stress für die Mitarbeitenden.
  • Die Mitarbeitenden verwenden ihre Zeit nicht für repetitive Aufgaben ohne Mehrwert.
  • Die Mitarbeitenden sind befähigt die Ressourcen, welche benötigt werden, selbstständig zu definieren, bereitzustellen und zu verwalten.
  • Als Team können wir Fehler rasch korrigieren. Wir versuchen nicht Fehler um jeden Preis zu vermeiden.
  • Verbesserungen werden kontinuierlich gemacht und ausgerollt. Grosse und risikoreiche «Big Bang» Projekte werden vermieden.
  • Funktionierende Software ist der Massstab: Implementation und automatisches Testing sind wichtiger als Meetings und Dokumente.

«Infrastructure as Code» (Morris 2016) basiert auf folgenden Prinzipen:

  • Systeme können einfach reproduziert werden.
  • Systeme sind wegwerfbar/ersetzbar («disposable»).
  • Systeme sind konsistent.
  • Prozesse sind reproduzierbar.
  • Das Design verändert sich ständig.

«Infrastructure as Code» (Morris 2016) gibt folgende Praktiken vor:

  • Konfigurationen sind in Definitions-Dateien abgelegt.
  • System und Prozesse sind selbst-dokumentiert.
  • Die gesamte Konfiguration ist unter Versionskontrolle.
  • Kontinuierliche automatische Tests für Systeme und Prozesse.
  • Kleine kontinuierliche Änderungen statt grosser Projekte.
  • Services sollen immer verfügbar sein.

Continuous Integration (Building/Testing Pipeline)

Änderungen am Quellcode bzw. an der Konfiguration jeglicher Applikationen und Systeme sind ausschliesslich im Prozessablauf der Building/Testing Pipeline zulässig. Die Code Base aller Applikation sowie die Konfiguration aller IT-Systeme sind komplett unter Git Versionskontrolle. Bei jedem «Git Commit» wird automatisch ein «Build» und «Test Run» angestossen. Der technische Ablauf eines «Change Requests» sieht inkl. «Continuous Integration» wie folgt aus:

  1. Der Entwickler macht ein Commit mit der Änderung im Code
  2. Der «Build» und «Test» Prozess wird automatisch angestossen.
  3. Nach erfolgreichem Building und Testing erstellt der IT-Mitarbeiter ein Release.
  4. Das Release wird ausgerollt (Testing, Production).

Informationssicherheit ISO/IEC 27001:2013

Unsere System verarbeiten hochsensitive personenbezogene Daten. Informationssicherheit ist daher Teil der DNA unseres Unternehmens. Wir führen ein Informationssicherheitsmanagementsystem und sind gemäss ISO/IEC 27001:2013 zertifiziert