Why I use PHP for CI tasks
I've previously posted about how to create a release with GitLab and Composer. It's actually my most popular post of all time (more popular than my home page)! It's a great feeling, but has been questioned by some:
- why would I do tasks like that?
- why would I use PHP for CI tasks?
The answer to the first is easy, it works the way I want it to, so I can create a release on my terms, rather than every single small change creating a release. It means if I work on multiple issues in a night, I'm not pushing out 3 or 4 releases in the space of an hour. That's no good to anyone, especially if one of those releases is buggy. Sure it means I don't strictly adhere to semantic releases, but it also means I don't have to tie myself into Git Flow as my workflow. I can work how I want to, as previously stated.
As for why I would use PHP for CI tasks? Simple. PHP has been my primary language now for around 15 years. Why wouldn't I do things in a way which is familiar and easy for me to understand?
I do the same at work. I create commands by extending the Symfony Console component. I can call it as I would any other CLI utility within CI, and perform the actions I need to. This brings the added bonus that everyone on the team can see what each command actually does. If there's an issue with one of the commands, they can pick up the task and work on it. It doesn't require the CI specialist to come in and work their magic to enhance a task or fix a bug. This helps keep our bus factor high, and reduces the time taken to train new people.
On top of that, I can ensure that the pipeline tasks have their own test suite to help prove their functionality and reduce the likelihood of failure. The tasks will adhere to existing coding standards to further reduce training and knowledge transfer.
I am the first to admit that there may be better tools suited to the tasks which I have implemented in PHP. But if these are things which are touched infrequently, then using a language unfamiliar to most of the team will only result in any changes being slow, and therefore an area people want to avoid.
If you need to create jobs for your CI pipeline which perform custom tasks (not simply run unit tests or deploy), then don't be ashamed to write those tasks in a language you know well, and which can do the task. Your team and/or your future self will thank you for it when it comes time to extend or maintain it. You will likely have the tools ready to debug the job without needing to open a new editor or project, and then remind yourself of how the jobs are coded.
