My company is trying to get some processes in order, have more accountability, be better in general. It's a good thing and I'm helping, even leading some of the projects. But now I am being asked to make a change request ticket for each software release. I dislike the idea, am I wrong?<p>This is what we currently do:<p>- All code is in github.<p>- All issues are in Jira.<p>- Almost all commits are connected to a Jira issue.<p>- We track versions in Jira.<p>- We put the tickets in the correct version when we release.<p>- We can do rollbacks with the click of a button.<p>- We have automated tests, but not enough; we rely a lot on manual testing right now. We are trying to fix this.<p>I managed to negotiate to the point of having all our change requests pre-approved and they'd be ok with us automating the ticket creation (eventually). They were quite surprised when I told them we release tens of time a week and that's because we inherited a system that has a lot of manual steps to release. I'd like to release tens of time a day. But in my opinion, it's still bureaucracy. It's still filling a ticket with tens of fields, most of which are not applicable for a software release. Obviously I'm being told it only takes 5 minutes but I worry. Bureaucracy eats your time 5 minutes at a time, until nothing is left.<p>I'm biased because no company I ever worked for had change request tickets for releases except one: banks. And banks are horrible places to work as a developer, which is why they pay so much. I hated every minute of working there, but the pay was good and it funded one of my startups. I don't want my company to be that and we can't afford it.<p>Any opinions? Any data? Any resources to help explain non-software people how the software world behaves? Am I overreacting here?