In my experience, while the Production Support team typically executes the final deployment, I am heavily involved in the preparation and coordination. Our process follows a structured release lifecycle:

1. Versioned Environments: We use dedicated application instances for each release to ensure isolation. For example, the first release of 2026 would be deployed under APP_NAME_26.1.
2. Database Management: To handle database changes, we consolidate all tables, views, stored procedures, and DML into a single Master SQL Script. This ensures execution order and reduces manual errors.
3. Deployment Execution:
4. Plugin Deployment: We first deploy any required plugins to ensure the environment supports the new code.
5. Database Updates: The Master SQL script is executed against the production database.
6. Code Migration: We follow a 'Promote-to-Production' model where we export the validated package from Pre-Prod and import it into the Production environment.
7. Risk Management: Before any changes begin, we always ensure the Maintenance Window is turned on in the Admin Console. This prevents user interference and ensures data integrity during the migration. After deployment, we conduct a smoke test before turning maintenance mode off.

Note: Every team may follow a slightly different deployment strategy, but the core principles remain the same: structure, consistency, and control. In interviews, the expectation isn’t that you follow a specific method—it’s that you understand how production deployments are typically handled and can explain the process clearly.