| 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... |
> 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.