Automatic updates in our projects
The typical IT person sometimes has only himself to blame for his fate: We prefer to deal with exciting challenges, technologies and software stacks or look for new things that we can sell to our customers. At some point, of course, daily business catches up with us and we have to take care for the operation of the applications we've designed. This also includes applying updates and security patches for the various 3rd party components that were used in the process. But let's be honest: Who likes to do that?
In addition, the frequency of updates increases enormously with growing complexity. So it's not at all unusual that on average every two days something has to be done in practically every project. And last but not least, the whole thing has to be tested by someone somehow.
However, there is also no point in riding out the updates. First, updates often bring improvements, for example in terms of performance. On the other hand, according to the current legal situation, you are obligated to regularly update the software.
Small-step updates, but please without monster bureaucracy
Now, as is well known, MFC has been practicing Kanban since the beginning of 2019. With Kanban, it is part of the concept that each employee selects the next task himself. Needless to say, the update tasks are not necessarily very popular. Logical: what is basically just a composer update, followed by a bit of Git foo, is of course not as exciting as the other tasks that might just be waiting. The typical developer usually wants to stay a problem solver, after all.
And exactly because we like to solve problems, something had to happen here urgently, true to the motto: "Automate the Boring Stuff". The result is a small script that does several things:
- Every day
composer updateruns in the project. The result is committed into a new branch calledsupport/autoupdate. - If the branch already exists, the script overwrites the existing one with the current state. This way all pending updates are collected in one branch.
- Finally, a merge request is created in GitLab in the project and assigned to the responsible project manager. The project manager can test the updated application and merge the branch with a click.
The entire process runs every working day at night, i.e. when you come into the office in the morning, the update branches are already ready and waiting to be tested. We developers are only needed for updates in case of errors or at most to create a release at the end. While the project managers are busy QA-ing the - inevitable - flood of upcoming updates, we can devote ourselves to the real challenges again.
The autoupdater script is written in PHP, but currently exists only in the form of a non-presentable proof-of-concept 😉 We are currently working on further developing the tool so that we can open-source it on GitHub. Once that happens, we'll update this blog post.
Update: You can find our autoupdater on GitHub in the meantime.
By the way, if you think "I can do that too!", then apply to join us!
Update June 2024
At the Web Camp Venlo 2023, we got to know https://github.com/renovatebot/renovateRenovate CLI. Renovate takes over the previously described tasks and generates merge requests for approval in our CI pipeline. Renovate supports not only Composer as a package manager but also many other languages and managers.
We now use Renovate for almost all package managers we employ, including CSS, JavaScript, and Docker in the infrastructure area. Therefore, we have decided to discontinue the maintenance of our auto-updater and archive the project.
Please feel free to share this article.
Comments
No comments yet.