{"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 ein, den Bericht von Alexander Sigachev von Inventos \u00fcber den \"Entwicklungs- und Testprozess mit Docker + Gitlab CI\" zu lesen.<\/strong><\/p>\n

<\/p>\n

Diejenigen, die gerade erst damit beginnen, den Entwicklungs- und Testprozess auf Basis von Docker + Gitlab CI einzuf\u00fchren, stellen oft grundlegende Fragen. Wo soll man anfangen? Wie soll man organisieren? Wie testen?<\/p>\n

<\/p>\n

Dieser Bericht ist gut, weil er strukturiert \u00fcber den Entwicklungs- und Testprozess mit Docker und Gitlab CI spricht. Der Bericht stammt aus dem Jahr 2017. Ich denke, dass man aus diesem Bericht Grundlagen, Methoden, Ideen und Erfahrungen sammeln kann. <\/p>\n

\n

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

F\u00fcr Interessierte bitte weiterlesen. <\/a><\/noindex><\/p>\n

<\/p>\n

Ich hei\u00dfe Alexander Sigachev. Ich arbeite bei der Firma Inventos. Ich werde \u00fcber meine Erfahrungen mit Docker und dar\u00fcber berichten, wie wir es schrittweise in Projekten im Unternehmen implementieren.<\/p>\n

<\/p>\n

Thema des Berichts: Entwicklungsprozess mit Docker und Gitlab CI. <\/p>\n

<\/p>\n

\"Der<\/p>\n

<\/p>\n

Das ist mein zweiter Bericht \u00fcber Docker. Zum Zeitpunkt des ersten Berichts nutzten wir Docker nur in der Entwicklung auf den Maschinen der Entwickler. Die Anzahl der Mitarbeiter, die Docker nutzten, lag bei etwa 2-3 Personen. Nach und nach haben wir Erfahrung gesammelt und sind etwas weitergekommen. Hier ist der Link zu unserem ersten Bericht<\/a><\/noindex>.<\/p>\n

<\/p>\n

Was wird in diesem Bericht behandelt? Wir werden unsere Erfahrungen teilen, welche Stolpersteine wir aufgesammelt haben und wie wir bestimmte Probleme gel\u00f6st haben. Es war nicht \u00fcberall sch\u00f6n, aber es hat uns erm\u00f6glicht, voranzukommen.<\/p>\n

<\/p>\n

Unser Motto: Dockerisiere 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 es in einem Unternehmen mehrere Teams gibt, ist der Programmierer eine gefragte Ressource. Es gibt Phasen, in denen ein Programmierer aus einem Projekt herausgerissen wird und f\u00fcr eine gewisse Zeit in ein anderes Projekt gegeben wird.<\/p>\n

<\/p>\n

Damit der Programmierer schnell einsteigen kann, muss er den Quellcode des Projekts herunterladen und m\u00f6glichst schnell eine Umgebung einrichten, die es ihm erm\u00f6glicht, die Aufgaben dieses Projekts weiter voranzutreiben.<\/p>\n

<\/p>\n

Normalerweise, wenn man von Null anf\u00e4ngt, wird in dem Projekt wenig Dokumentation gef\u00fchrt. Die Informationen zur Einrichtung haben nur die alten Hasen. Eigenst\u00e4ndig richten die Mitarbeiter ihren Arbeitsplatz in ein oder zwei Tagen ein. Um dies zu beschleunigen, haben wir Docker eingesetzt.<\/p>\n

<\/p>\n

Der n\u00e4chste Grund sind die Standardisierungen der Einstellungen in der Entwicklung. Nach meiner Erfahrung zeigen die Entwickler immer Initiative. In jedem f\u00fcnften Fall wird eine benutzerdefinierte Domain eingef\u00fchrt, zum Beispiel vasya.dev. Nebenan sitzt Nachbar Petja, der die Domain petya.dev hat. Sie entwickeln eine Website oder eine Systemkomponente mit diesem Domainnamen.<\/p>\n

<\/p>\n

Wenn das System w\u00e4chst und diese Domainnamen in die Konfigurationen gelangen, entsteht ein Konflikt zwischen den Entwicklungsumgebungen und der Weg zur Website wird \u00fcberschrieben.<\/p>\n

<\/p>\n

Das Gleiche passiert mit den Datenbankeinstellungen. Manche k\u00fcmmern sich nicht um die Sicherheit und arbeiten mit dem leeren Passwort root. Bei manchen verlangte beim Setup MySQL ein Passwort und es stellte sich heraus, dass es 123 war. Oft kommt es vor, dass die Datenbankkonfiguration st\u00e4ndig ge\u00e4ndert wurde, je nach den Commits des Entwicklers. Manche haben die Konfiguration korrigiert, andere nicht. Es gab Tricks, bei denen wir eine Testkonfiguration in die .gitignore<\/code> und jeder Entwickler musste die Datenbank installieren. Das erschwerte den Startprozess. Man muss neben allem anderen auch an die Datenbank denken. Die Datenbank muss initialisiert, das Passwort muss angegeben, ein Benutzer muss festgelegt und eine Tabelle muss erstellt werden und so weiter.<\/p>\n

<\/p>\n

Ein weiteres Problem sind die unterschiedlichen Versionen von Bibliotheken. Oft ist es so, dass der Entwickler mit verschiedenen Projekten arbeitet. Es gibt ein Legacy-Projekt, das vor f\u00fcnf Jahren (seit 2017) gestartet wurde. Zu Beginn wurde mit MySQL 5.5 gearbeitet. Es gibt auch moderne Projekte, bei denen wir versuchen, bereits modernere MySQL-Versionen wie 5.7 oder \u00e4lter (im Jahr 2017) zu implementieren.<\/p>\n

<\/p>\n

Jeder, der mit MySQL arbeitet, wei\u00df, dass diese Bibliotheken Abh\u00e4ngigkeiten mit sich ziehen. Es ist ziemlich problematisch, zwei Datenbanken gleichzeitig zu starten. Zumindest ist es schwierig, alte Clients mit einer neuen Datenbank zu verbinden. Das f\u00fchrt seinerseits zu mehreren Problemen.<\/p>\n

<\/p>\n

Das n\u00e4chste Problem tritt auf, wenn der Entwickler auf seinem lokalen Rechner arbeitet, wobei er lokale Ressourcen, lokale Dateien und lokalen RAM verwendet. Alle Interaktionen w\u00e4hrend der Entwicklung der L\u00f6sungen erfolgen im Rahmen dessen, dass alles auf einem einzigen Rechner funktioniert. Ein Beispiel w\u00e4re, wenn wir in der Produktion drei Backend-Server haben und der Entwickler Dateien im Root-Verzeichnis speichert, von wo aus nginx Dateien f\u00fcr die Anfragen abruft. Wenn dieser Code in die Produktion gelangt, liegt das Problem darin, dass die Datei nur auf einem der drei Server vorhanden ist.<\/p>\n

<\/p>\n

Aktuell entwickelt sich der Bereich der Mikrodienste. Wenn wir unsere gro\u00dfen Anwendungen in kleinere, miteinander interagierende Komponenten aufteilen. Dies erm\u00f6glicht es, die Technologien f\u00fcr den jeweiligen Aufgabenstapel auszuw\u00e4hlen. Au\u00dferdem erlaubt es eine bessere Aufteilung der Arbeit und der Verantwortungsbereiche unter den Entwicklern.<\/p>\n

<\/p>\n

Frontend-Entwickler, die in JS entwickeln, haben praktisch keinen Einfluss auf das Backend. Der Backend-Entwickler hingegen entwickelt in unserem Fall Ruby on Rails und st\u00f6rt die Frontend-Entwicklung nicht. Die Interaktion erfolgt \u00fcber APIs.<\/p>\n

<\/p>\n

Als Bonus konnten wir mit Docker die Ressourcen auf Staging optimieren. Jedes Projekt ben\u00f6tigte aufgrund seiner Spezifikationen bestimmte Einstellungen. Physisch mussten entweder separate virtuelle Server bereitgestellt und individuell konfiguriert werden oder es war n\u00f6tig, eine variable Umgebung zu teilen, sodass die Projekte, je nach Version der Bibliotheken, sich gegenseitig beeinflussen konnten.<\/p>\n

<\/p>\n

\"Der<\/p>\n

<\/p>\n

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

<\/p>\n