{"id":32526,"date":"2019-10-31T21:47:32","date_gmt":"2019-10-31T18:47:32","guid":{"rendered":"https:\/\/prohoster.info\/blog\/protsess-razrabotki-i-testirovaniya-s-docker-i-gitlab-ci\/"},"modified":"2019-10-31T21:47:32","modified_gmt":"2019-10-31T18:47:32","slug":"protsess-razrabotki-i-testirovaniya-s-docker-i-gitlab-ci","status":"publish","type":"post","link":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/protsess-razrabotki-i-testirovaniya-s-docker-i-gitlab-ci","title":{"rendered":"Der Entwicklungs- und Testprozess mit Docker und GitLab CI","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Ich lade Sie ein, sich mit der Zusammenfassung des Berichts von Alexander Sigachev von Inventos \"Entwicklungs- und Testprozess mit Docker + Gitlab CI\" vertraut zu machen.<\/strong><\/p>\n

<\/p>\n

Diejenigen, die gerade erst beginnen, den Entwicklungs- und Testprozess auf Basis von Docker + GitLab CI einzuf\u00fchren, stellen h\u00e4ufig grundlegende Fragen. Wo fange ich an? Wie organisiere ich das? Wie teste ich es?<\/p>\n

<\/p>\n

Dieser Vortrag ist besonders, da er strukturiert \u00fcber den Entwicklungs- und Testprozess unter Verwendung von Docker und GitLab CI berichtet. Der Vortrag stammt aus dem Jahr 2017. Ich denke, dass man aus diesem Vortrag Grundlagen, Methoden, Ideen und Erfahrungen sammeln kann. <\/p>\n

\n

\r\n \"Video\r\n
<\/div>\r\n <\/div><\/center><\/p>\n

Wer interessiert ist, ist herzlich eingeladen, weiterzulesen. <\/a><\/noindex><\/p>\n

<\/p>\n

Mein Name ist Alexander Sigachev. Ich arbeite bei Inventos. Ich werde von meinen Erfahrungen mit Docker berichten und wie wir es schrittweise in unsere Projekte im Unternehmen integrieren.<\/p>\n

<\/p>\n

Thema des Vortrags: Entwicklungsprozess mit Docker und GitLab CI. <\/p>\n

<\/p>\n

\"Der<\/p>\n

<\/p>\n

Das ist mein zweiter Vortrag \u00fcber Docker. Zum Zeitpunkt des ersten Vortrags nutzten wir Docker nur in der Entwicklungsphase auf den Maschinen der Entwickler. Die Anzahl der Mitarbeiter, die Docker verwendeten, lag bei etwa 2-3 Personen. Nach und nach haben wir Erfahrungen gesammelt und sind ein St\u00fcck weitergekommen. Link zu unserem erster Bericht<\/a><\/noindex>.<\/p>\n

<\/p>\n

Was wird in diesem Bericht behandelt? Wir teilen unsere Erfahrungen dar\u00fcber, welche Stolpersteine wir gesammelt haben und wie wir Probleme gel\u00f6st haben. Es war nicht immer einfach, aber es hat uns erm\u00f6glicht, weiter voranzukommen.<\/p>\n

<\/p>\n

Unser Motto: Docker alles, was in unsere H\u00e4nde kommt.<\/p>\n

<\/p>\n

\"Der<\/p>\n

<\/p>\n

Welche Probleme l\u00f6sen wir?<\/p>\n

<\/p>\n

Wenn in einem Unternehmen mehrere Teams existieren, ist der Programmierer eine gefragte Ressource. Es gibt Phasen, in denen Programmierer aus einem Projekt herausgezogen und f\u00fcr eine gewisse Zeit in ein anderes Projekt gegeben werden.<\/p>\n

<\/p>\n

Damit ein Programmierer schnell einsteigen kann, muss er den Quellcode des Projekts herunterladen und so schnell wie m\u00f6glich eine Umgebung starten, die es ihm erm\u00f6glicht, die Aufgaben dieses Projekts zu l\u00f6sen.<\/p>\n

<\/p>\n

Normalerweise gibt es, wenn man von Grund auf neu anf\u00e4ngt, wenig Dokumentation im Projekt. Die Informationen zur Einrichtung haben nur die alten Hasen. Die Mitarbeiter richten ihren Arbeitsplatz normalerweise in ein oder zwei Tagen selbst ein. Um diesen Prozess zu beschleunigen, haben wir Docker verwendet.<\/p>\n

<\/p>\n

Ein weiterer Grund sind die Standardisierungen der Einstellungen in der Entwicklung. Meiner Erfahrung nach zeigen Entwickler immer Initiative. In jedem f\u00fcnften Fall wird eine benutzerdefinierte Domain wie vasya.dev eingef\u00fchrt. Daneben sitzt Nachbar Petja, der die Domain petya.dev hat. Sie entwickeln eine Website oder ein Systemkomponente unter Verwendung dieses Domainnamens.<\/p>\n

<\/p>\n

Wenn das System gr\u00f6\u00dfer wird und diese Domainnamen in die Konfigurationen gelangen, entstehen Konflikte zwischen den Entwicklungsumgebungen und der Pfad der Website wird \u00fcberschrieben.<\/p>\n

<\/p>\n

Das Gleiche passiert mit den Datenbankeinstellungen. Manche k\u00fcmmern sich nicht um die Sicherheit und arbeiten mit einem leeren root-Passwort. Bei anderen wurde w\u00e4hrend der MySQL-Installation ein Passwort gefordert und das Passwort war einfach 123. Es kommt h\u00e4ufig vor, dass die Datenbankkonfiguration st\u00e4ndig je nach Commit des Entwicklers ge\u00e4ndert wurde. Jemand hat die Konfiguration angepasst, jemand anderer nicht. Es gab Tricks, bei denen wir eine Art Testkonfiguration ins .gitignore<\/code> Jeder Entwickler muss eine Datenbank einrichten, was den Startprozess kompliziert. Man darf nicht vergessen, dass auch die Datenbank ber\u00fccksichtigt werden muss. Sie muss initialisiert, das Passwort eingegeben, ein Benutzer angelegt und eine Tabelle erstellt werden, und so weiter.<\/p>\n

<\/p>\n

Ein weiteres Problem sind die unterschiedlichen Versionen der Bibliotheken. H\u00e4ufig arbeitet ein Entwickler an verschiedenen Projekten. Es gibt ein Legacy-Projekt, das vor f\u00fcnf Jahren (seit 2017 \u2013 Anm. d. Red.) begonnen wurde und mit MySQL 5.5 gestartet ist. Daneben gibt es moderne Projekte, in denen wir versuchen, bereits aktuellere Versionen von MySQL einzuf\u00fchren, etwa 5.7 oder h\u00f6her (im Jahr 2017 \u2013 Anm. d. Red.).<\/p>\n

<\/p>\n

Wer mit MySQL arbeitet, wei\u00df, dass diese Bibliotheken Abh\u00e4ngigkeiten mit sich bringen. Es ist ziemlich problematisch, zwei Datenbanken gleichzeitig zu betreiben. Zumindest ist es schwierig, \u00e4ltere Clients mit einer neuen Datenbank zu verbinden. Dies f\u00fchrt seinerseits zu mehreren Problemen.<\/p>\n

<\/p>\n

Das n\u00e4chste Problem ist, dass der Entwickler auf seiner lokalen Maschine arbeitet, wobei er lokale Ressourcen, lokale Dateien und lokalen RAM verwendet. Alle Interaktionen w\u00e4hrend der Entwicklung der L\u00f6sungen finden innerhalb der Rahmenbedingungen statt, dass alles auf einer Maschine funktioniert. Ein Beispiel ist, wenn wir in der Produktion drei Backend-Server haben und der Entwickler Dateien im Stammverzeichnis speichert, von dem aus Nginx die Dateien zur Beantwortung von Anfragen abruft. Wenn solcher Code in die Produktion gelangt, ist die Datei nur auf einem der drei Server vorhanden.<\/p>\n

<\/p>\n

Derzeit entwickelt sich der Bereich der Microservices. Wenn wir unsere gro\u00dfen Anwendungen in kleinere, miteinander kommunizierende Komponenten aufteilen. Dies erm\u00f6glicht es, f\u00fcr spezifische Aufgaben den passenden Technologie-Stack auszuw\u00e4hlen. Au\u00dferdem erlaubt es, die Arbeit und Verantwortlichkeiten zwischen den Entwicklern aufzuteilen.<\/p>\n

<\/p>\n

Der Frontend-Entwickler, der mit JS arbeitet, hat kaum Einfluss auf das Backend. Der Backend-Entwickler hingegen entwickelt in unserem Fall mit Ruby on Rails, was das Frontend nicht beeintr\u00e4chtigt. Die Interaktion erfolgt \u00fcber APIs.<\/p>\n

<\/p>\n

Als Bonus konnten wir mit Docker die Ressourcen in der Staging-Umgebung optimieren. Jedes Projekt erforderte aufgrund seiner Spezifit\u00e4t bestimmte Einstellungen. Physisch mussten entweder separate virtuelle Server bereitgestellt und individuell konfiguriert werden oder wir mussten eine variable Umgebung teilen, was dazu f\u00fchrte, dass die Projekte je nach Version der Bibliotheken Einfluss aufeinander hatten.<\/p>\n

<\/p>\n

\"Der<\/p>\n

<\/p>\n

Werkzeuge. Was verwenden wir? <\/p>\n

<\/p>\n