The traditional methodology of software deployment, still alive and well in corporate America, is a process defined and managed by issuing tickets. These tickets allow other teams to perform functions that a single developer, or team, cannot perform on their own.
This process also very manual and requires more reviews than is necessary. You may think that I am against tickets, reviews, or the process entirely, but you would only be partially right.
I am against unnecessary work. I am 100% in favor of building systems and processes to support them that allow for business goals to be accomplished. Most businesses have the goal of NOT losing money. It has been my experience that the larger the company, the more process is present. This means more tickets for a growing number of teams to perform their specific functions. Given the size of a company, and the number of zeroes in the revenue column, the process generally grows larger
Reviews must happen, even if they are automated, to record the review in the ticketing system. Regardless of the system you use or how the workflow is set up, somebody, or something, in your organization cares about that system. So should you.
The tickets and their history are there for others in your organization. You may not care about a change request ticket and think it is truly a CYA activity for moving your software through environments. Those tickets exist for others to perform their job. You may not know them but they do exist. They are doing their job much like yourself. When working with ticketing systems, nobody does anything as fast as you would like. It is an inefficient communication system, but it is a communication system.
Ticketing systems are the shared consciousness of an organization. If something happens there is probably a ticket. If you encounter an individual who asks for a ticket to do something, pretty much anything (you know the type), they are not trying to avoid work. They are trying to document their work in the established system that the organization uses
