When developing a website using the University's Drupal Enterprise service, there are many best practices you should follow. Here are a few of them.
Grant drupa001 read access to your repository
OIT admins will use the drupa001 account to move your code from the repository to the environment.
Work and test in DEV
There are three environments for your site: Development, Stage, and Production. You should always work and test in the Development branch. When you are ready to deploy your site (or changes you've been working on), request the code be moved from Dev to Stage. Stage is where your team can test everything. If everything is working fine, then you can request the code be deployed to Production.
Send an email to firstname.lastname@example.org to request code deployment(s).
Don't deploy code at the end of the day (or before weekends, holidays, etc)
If you really need to deploy your code at the end of the day, you can certainly do so. However, requests for code deployment are generally handled M-F 8:00 am - 4:30 pm. Support availability is defined in the Service Level Agreement.
Don't push code to your repository unless you want it in that environment
Don't incrementally push code to your repository. When a request is made by anyone to migrate their code, all code on that subscription is migrated at the same time. If you and another person each have a site on the same subscription, and they request the code to migrate to one of the environments, your code will also be migrated.
Remove users when they leave
You are responsible for managing your sites' user accounts. If someone leaves your group and no longer needs to log in to your site, you should deactivate their account.
You should document as much as you possibly can.
Make sure you document how your site is built.
Add contextual help to inform your contributors how to use your site. For example, add help text to fields in the content types.