• For us, indexes are a change to source controlled objects. We use visual studio database projects so since the database project needs to be updated and deployed, an index is technically a regular change. I like the process we follow where I work because it adds some flexibility in cases where changes are anticipated to be transparent to end users and other systems.

    Our process for an index on a non-SOX system would be:
    - Add the index to the db project (create a HF branch if applicable)
    - Deploy to QA/UAT environments
    - Run expected tests (minimal, regression typically not required).
    - Enter a change notification
    - Deploy to PROD environment (merge HF branch if applicable)
    Typical time for process end-to-end is ~20minutes

    What's new to me in our process is the change notification. For smaller changes that don't require an outage and have been confirmed transparent we don't follow the normal change control approval process. However since any change has the potential to impact performance or user experience we follow a change notification process. The notification process is to post a message with the details and schedule of the change being made the "Change Notification Channel" that we setup in MS Teams. If someone has concerns they can raise them in the channel up to the change's scheduled time (no less than 15 minutes from notification). When users report issues, the help desk or system admins can search the change notifications for related changes and report the issue in the thread and get help. This has made us much more agile and has sped up the process of "little" changes.

    -