[bena]

I feel both sides of this one.

Yes, creating automated processes would make things easier, but the time it would take to automate the process would take too much time before you have to deliver.

So everyone knows what needs to be done, everyone recognizes that it would help things, but no one can put down what they're juggling to handle it.

Sometimes it takes bringing on a person just to take on that project as its own thing to relieve the pressure on the existing team.

[leghifla]

Regarding a dedicated person to handle the CI, here is my experience.

In the small company I am working now, I had setup a adhoc deployment script that was working fine, took less than 5min (with no user interaction) on my dev PC. Since it is not a SaaS, our release cycle was a bit slower than wanted, 1 or 2 times per month, depending on circumstances.

A guy was hired and he wanted to speed this up. I explained clearly that the build/deploy script was not the cullprit of the "slow" release cycle. It takes time to decide was is ready for production, write a nice changelog for users (not just collecting git messages), testing on the custom hardware...

That is why it took me an hour to half a day when the boss said: we need a release today. The above guy was justifying its work by: "After I am done, you will just need to put a tag and the rest will be automatic". I could not convince my boss this was fantasy land.

Result 3 years later: we have a "nice" CI which rebuild the world several times per day. But we are doing maximum 2 official releases per year, with much more stress. We had a few "releases" which needed very urgent hot-fixes because of last-minute changes and not enough testing on hardware.

And the CI person is constantly tweaking bits of the CI (it has become part of his job), breaking thing here and there.

I long for the old days...

[scatters]

Then I don't understand what your issue is.

> We had a few "releases" which needed very urgent hot-fixes because of last-minute changes and not enough testing on hardware.

That sounds like the problem is that the CI is not testing on hardware, or that you're running ad-hoc manual tests on hardware that could be automated or at least formalized.

[scatters]

Your problem is not the CI. It's that the CI does not test the custom hardware.

You need a hardware testing engineer who can automate the tests that you're currently running manually.

[leghifla]

The initial script was fine, but not ideal. The CI is better in this regards.

The CI is not the problem, sure. But it is not the solution either. That was my point.

[euroderf]

The strategic use of interns. With obvious ROI that makes subsequent interns easier to acquire.