Like continuous deployment, you can you also continuous improvement, with these two crucial steps:

• Release readiness checklist
• post-release "lesson learned" meeting.

Many of members our our team are former military, air force, marines, navy. And they are used to checklists, and to most-mortem analysis. They say that all these lessons are "written in blood" because we learned them by making mistakes and paying for them. It is expensive way to learn, so you want to learn the lesson first time you make the mistake.

Before every release we have "Release readiness" meeting where we go over the release with interested parties, decide responsibilities, and follow the checklist. Exactly like when jet is preparing for takeoff.

After every release we have "lessons learned" session, where anyone can suggests what went wrong (or nearly wrong), and how our process can be improved to prevent it from happening next time. Sometimes we add new questions to checklist, if we feel that some check would prevent something preventable. Sometimes teams add entries to their internal checklists.

So decision "is release ready" is not made by QA team, but by readiness review team, after going over checklist. QA just summons the meeting, but business managers make the decision.

It is a decision based not only on manual testing and running automated e2e test, but also unit tests, preparedness for all other teams (documentation, sales, training), etc.

Like continuous deployment, you can you also continuous improvement, with these two crucial steps:

• Release readiness checklist
• post-release "lesson learned" meeting.

Many of members our our team are former military, air force, marines, navy. And they are used to checklists, and to post-mortem analysis. They say that all these lessons are "written in blood" because we learned them by making mistakes and paying for them. It is expensive way to learn, so you want to learn the lesson first time you make the mistake.

Before every release we have "Release readiness" meeting where we go over the release with interested parties, assign responsibilities, and follow the checklist. Exactly like when jet is preparing for takeoff.

After every release we have "lessons learned" session, where anyone can suggests what went wrong (or nearly wrong), and how our process can be improved to prevent it from happening next time. Sometimes we add new questions to checklist, if we feel that some check would prevent something preventable. Sometimes teams add entries to their own internal checklists (so check is done internally and does not appear on final checkist).

So decision "is release ready" is not made by QA team, but by readiness review team, after going over checklist. QA just summons the meeting, business managers make the decision after evaluating the evidence.

It is a decision based not only on manual testing and running automated e2e test, but also unit tests, preparedness for all other teams (documentation, sales, training), etc. Some teams are involved in every release, some (like marketing) only as necessary.