Each vendor will have a group in GitLab. Inside that group will be subgroup for each site that the vendor works on. Typically, these site-subgroups will contain the site's custom code (Theme/Modules) and the site's config.

There will be at least two branches for each of those repos, test and main/master. If a third branch is needed for another non-prod site then it will likely be named 'development'. Those branches will be deployed to the site of the same name (ex. test branch of the Custom Code repo will be pulled into the test site build process which will be deployed to the test site).

Note: Users will need to log into GitLab before they are able to be added to any code repos.

The site build is done via a private GitLab repo that will use composer to build the Drupal site and will clone/place the Custom Code repos. Once the build is complete it will trigger an external system to queue the build for deployment.

The site build and site deploy can take some time (about 10-15 minutes) and is occasionally prone to failures due to lack of build resources.

Each of Custom Code repos will have a manual CI/CD job that can kick off a site build and deployment. If you make changes to multiple Custom Code repos for a site then you can kick off the build after your commit your final change. This will pull in all changes for each of the Custom Code repos.

Once a job is kicked off from one of the Custom Code repos it will trigger a build of the same branch of the Site Build repo. For example, kicking off a build from the test branch of the Custom Code repo will start a start a build from the test branch of the site build repo. 

Site builds and deployments will only be setup for non-production branches.

Emails can be configured to alert you when the site build is complete and when the build has deployed. Provide us with a list of what emails you'd like to receive the alerts and we can add those appropriately.

Scenario: Changes are required to a custom module, the theme, and some minor configuration changes.

Suggested Workflow:

1. Export the configuration from the production site (or ask DHTS for a backup of the production site).
2. Import the configuration or backup into local environment
3. Make the changes and perform testing
4. Export the Configuration from the local environment
5. Commit the changes to the appropriate GitLab repositories
6. Navigate to the CI/CD tab of one of the repos and kick off the Manual Build Trigger
7. Wait for email notification that the build has been completed and deployed (request that your email is added to this step if you'd like to receive the deployment notifications)
8. Confirm Changes look good on the Web Services-DHTS hosted test site
9. Merge changes to main/master branch of the altered repos.
10. Email Web Services-DHTS (likely Aaron Nelson) with a brief description of the changes (they are put in our product change tracking system).
11. Web Services-DHTS will fill out a change tracking form, backup the site, build the site from the GitLab Site Build repo, and deploy the resulting build to production
12. Web Services-DHTS will email the vendor that the deployment is complete for the vendor to verify and make any final changes on the production site as needed.

Notes:

• Web Services-DHTS does not perform deployments to Production on Fridays or the days surrounding a major holiday.
  • (If something goes wrong, it is harder to get assistance over the weekend or during holidays which can result in longer issue resolution time).
• Web Services-DHTS will routinely re-run the build on the main/master branches to perform security updates or other actions.   By default, the main/master branch of the custom code repos will always be pulled from by their most recent commit.  Any code committed to the main/master branch should be production ready and Web Services-DHTS should be aware of the changes.
• The build process can take a while so it is recommended to only kick off the build from the custom code repos once you are done (or close to done) with your changes.
• The product change tracking process (required by Duke policies) involves multiple steps - it is recommended to batch changes for production deployment if possible.
  • one push to production on a monday is preferred over 4 small pushes throughout the week