EN
How we deploy Automating processes of building software
As a software company we are obsessed with automating our own processes to get things done faster. To have an edge against other competitors in our field (selling Odoo) we developed some features that we published in the Odoo store as apps. This requiered us to have a repository on GitHub. We use the same apps in our own client solutions and last month we published our PyPI repository. Keeping this many places up to date is something no one can or should do manually.
Luckily this was something we knew from the beginning when we started MuK IT. All repeatable processes that don't need human interaction need to be automated. We are still not there with many parts of our company but software is the core of what we are selling. The goal was to develop faster by just concentrating on the development and fixing bugs instead of publishing and deploying. Combined with our Open Source strategy this gives us the ability to react faster to bugs and fix them everywhere with a commit. At least for us. Someone using this app still needs to download and upgrade it.
Everyone in software knows about Jenkins. It's one of the most popular continous integration tools out there. Jenkins was our first approach to automate our software deployment. This totally failed for various reasons. For one it was expensive in resources and two I think it was too inconvenient at that time. Searching for solutions we tried the CI system of GitLab, our git repository. Having our CI tool in our git repository always present was the incentive we needed to focus on optimizing this process.
GitLab CI
Thanks to Gitlab we could move our CI from Jenkins (as we had planned) to our GIT repository. Saving us a lot of time, work and even real money.
Text and image block
At this time we tested software on our local machines. At first this wasn't a problem but as we had more to do and more apps to maintain this got time consuming. We knew this was the first thing we need to get rid of. At the same time we were changing our infrastructure to kubernetes. So we wanted to combine this things. We wrote a docker image that we use for our clients and ourselves and we started testing against this image with everything installed that we use. When you push to the repository GitLab looks at a file called gitlab-ci.yml and decides what to do. In our case this was to tell kubernetes to run a container with our testimage and run the tests. After this is done GitLab knows if the test was successful or not. So this was our first simple CI pipeline.
The next thing we added was lint testing. For those who don't know lint, lint is a tool that analyzes source code for errors and stylistic problems. Then came a publishing step and recently we added a step for testing security (with bandit). As resources cost money we had to decide what job gets triggered when. Our current strategy is that lint and security tests only get triggered if you say so in the commit and that the publishing works with tagging a version in our repository.
Here is some example code of our gitlab-ci.yml structure:
stages:
- lint
- bandit
- test
- publish
...
lint-python:
image: some.repository.com/odoo-test:11.0
stage: lint
only:
variables:
- $CI_COMMIT_MESSAGE =~ /[lint]/
script:
- pylint --load-plugins=pylint_odoo -e odoolint --disable=${PYLINT_DISABLE} --max-line-length=${PYLINT_MAX} ${CI_PROJECT_DIR}
allow_failure: true
As I'm a very big fan of this topic, probably a lot of software engineers are, there will be more on this in the future. We are always working on making our processes faster and better because this gives us the ability to concentrate on the more important things like talking to customers or developing features. If someone wants to get in touch with Kerrim to talk about this topic don't hesitate to send Kerrim an email to kerrim.abdelhamed@mukit.at.
DE
Wie wir automatisierte Prozesse der Softwareentwicklung einsetzen
Als Softwareunternehmen sind wir davon besessen, unsere eigenen Prozesse zu automatisieren, um die Dinge schneller zu erledigen. Um einen Vorteil gegenüber anderen Mitbewerbern in unserem Bereich (Verkauf von Odoo) zu haben, haben wir einige Features entwickelt, die wir im Odoo Store als Apps veröffentlicht haben. Dies erforderte ein Repository auf GitHub. Wir verwenden die gleichen Anwendungen in unseren eigenen Client-Lösungen und haben im letzten Monat unser PyPI-Repository veröffentlicht. Diese vielen Orte auf dem neuesten Stand zu halten, ist etwas, was niemand manuell tun kann oder sollte.
Zum Glück wussten wir das von Anfang an, als wir MuK IT gründeten. Alle wiederholbaren Prozesse, die keine menschliche Interaktion erfordern, müssen automatisiert werden. Wir sind immer noch nicht mit vielen Teilen unseres Unternehmens da, aber Software ist der Kern dessen, was wir verkaufen. Das Ziel war es, schneller zu entwickeln, indem man sich nur auf die Entwicklung und Fehlerbehebung konzentrierte, anstatt sie zu veröffentlichen und zu verteilen. Zusammen mit unserer Open-Source-Strategie gibt uns das die Möglichkeit, schneller auf Fehler zu reagieren und diese überall mit einem Commit zu beheben. Zumindest für uns. Jemand, der diese Anwendung benutzt, muss sie noch herunterladen und aktualisieren.
Jeder in der Software kennt Jenkins. Es ist eines der beliebtesten Tools zur kontinuierlichen Integration. Jenkins war unser erster Ansatz zur Automatisierung unserer Softwareverteilung. Dies ist aus verschiedenen Gründen völlig gescheitert. Zum einen war es teuer in den Ressourcen und zum anderen war es meiner Meinung nach damals zu unpraktisch. Auf der Suche nach Lösungen haben wir das CI-System von GitLab, unserem Git-Repository, ausprobiert. Die ständige Präsenz unseres CI-Tools in unserem git-Repository war der Ansporn, uns auf die Optimierung dieses Prozesses zu konzentrieren.
GitLab CI
Dank Gitlab konnten wir unsere CI von Jenkins (wie geplant) in unser GIT-Repository verschieben. Das spart uns viel Zeit, Arbeit und sogar echtes Geld.
Text- und Bildblock
Zu dieser Zeit haben wir Software auf unseren lokalen Maschinen getestet. Zuerst war das kein Problem, aber da wir mehr zu tun hatten und mehr Apps zur Verfügung standen, wurde es zeitraubend. Wir wussten, dass dies das erste war, was wir loswerden mussten. Gleichzeitig haben wir unsere Infrastruktur auf kubernetes umgestellt. Also wollten wir diese Dinge kombinieren. Wir haben ein Docker-Image geschrieben, das wir für unsere Kunden und uns selbst verwenden, und wir haben damit begonnen, dieses Image mit allem, was wir verwenden, zu testen. Wenn Sie in das Repository schieben, betrachtet GitLab eine Datei namens gitlab-ci.yml und entscheidet, was zu tun ist. In unserem Fall ging es darum, kubernetes anzuweisen, einen Container mit unserem Testbild laufen zu lassen und die Tests durchzuführen. Danach weiß GitLab, ob der Test erfolgreich war oder nicht. Das war also unsere erste einfache CI-Pipeline.
Das nächste, was wir hinzugefügt haben, waren Fusseltests. Für diejenigen, die Fusseln nicht kennen, ist Fusseln ein Werkzeug, das den Quellcode auf Fehler und stilistische Probleme analysiert. Dann kam ein Veröffentlichungsschritt und vor kurzem haben wir einen Schritt zum Testen der Sicherheit (mit Bandit) hinzugefügt. Da Ressourcen Geld kosten, mussten wir entscheiden, welcher Job wann ausgelöst wird. Unsere aktuelle Strategie ist, dass Fussel- und Sicherheitstests nur dann ausgelöst werden, wenn Sie dies im Commit angeben und dass das Publizieren mit dem Tagging einer Version in unserem Repository funktioniert.
Hier ist einige Beispiel-Code unserer gitlab-ci.yml-Struktur:
Stufen:
- Fussel
- Bandit
- ausprobieren
- herausgeben
...
Lint-Python:
Bild: some.repository.com/odoo-test:11.0
Stufe: Fussel
nur:
Variablen:
- $CI_COMMIT_MESSAGE =~ /[Fussel]/
Drehbuch:
- pylint --load-plugins=pylint_odoo -e odoolint --disable=${PYLINT_DISABLE} --max-Zeilenlänge=${PYLINT_MAX} ${CI_PROJECT_DIR}
allow_failure: true
Da ich ein sehr großer Fan dieses Themas bin, wahrscheinlich viele Software-Ingenieure, wird es in Zukunft mehr dazu geben. Wir arbeiten ständig daran, unsere Prozesse schneller und besser zu gestalten, weil wir uns so auf die wichtigeren Dinge wie Kundengespräche oder die Entwicklung von Features konzentrieren können. Wenn jemand mit Kerrim in Kontakt treten möchte, um über dieses Thema zu sprechen, zögert nicht, Kerrim eine E-Mail an kerrim.abdelhamed@mukit.at. zu schicken.
by Kerrim
You want to test our ERP-System?
Demo.mukit.at
acc: demo
pw: demo
If you have any questions contact me or visit our website:
Subscribe to our youtube channel, so you dont miss any new videos: