Skip to content

Commit 1172c46

Browse files
mdyoung3mdyoung3
committed
Adding markdowns
Updated document
1 parent de92e5f commit 1172c46

File tree

3 files changed

+267
-0
lines changed

3 files changed

+267
-0
lines changed

‎.github/DEPLOYMENT_CHECKLIST_VPGE.md‎

Lines changed: 33 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,33 @@
1+
### 🔁 Rollback Preparedness
2+
3+
- [ ] **Database snapshot created**
4+
5+
- [ ] **Files directory backed up** (if relevant)
6+
7+
- [ ] **Feature toggle or revert plan documented**=
8+
9+
- [ ] **Rollback command tested locally or on staging**
10+
_Examples:_
11+
```bash
12+
drush sql:drop -y && drush sql:cli < /backups/prod/YYYY-MM-DD--latest.sql
13+
rsync -avz backups/prod/files/ web/sites/default/files/
14+
drush cr
15+
```
16+
17+
- [ ] **Deployment risks identified and documented**
18+
_e.g., New fields on existing content types, views changes, custom JS behavior_
19+
20+
**Risks:**
21+
- Content type: `Fellowship`
22+
- View: `Application periods by status`
23+
- JS: `deadlineCountdown()`
24+
25+
- [ ] **Time-sensitive changes validated against real content**
26+
27+
---
28+
29+
### 🔄 Manual Rollback Steps (if needed)
30+
31+
If rollback is required, follow this order:
32+
1. Restore database
33+
2. Set code to previous tagged release

‎.github/VPGE_RELEASE.md‎

Lines changed: 160 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,160 @@
1+
## VPGE Release Process – Tag, Deploy, Release
2+
3+
1. Preparation: Checkout & Compare
4+
5+
Checkout the latest development branch:
6+
7+
git checkout dev && git fetch && git pull
8+
9+
Compare dev to main to see what changes are included:
10+
11+
git log ^main dev
12+
13+
Use this log to draft changelog/release notes.
14+
15+
2. Determine Version Number
16+
17+
Check CHANGELOG.md or previous release tags to determine the next version.
18+
19+
Examples:
20+
21+
1.0.0
22+
23+
1.1.0-beta1
24+
25+
3. Create Release Branch
26+
27+
Start from dev:
28+
29+
git checkout dev
30+
31+
Create a release branch:
32+
33+
git checkout -b release-<VERSION>
34+
# e.g. git checkout -b release-1.0.0
35+
36+
4. Update Version References (if needed)
37+
38+
Update any hardcoded version strings (module info.yml files, README.md, etc.).
39+
40+
Confirm with past PRs if/what to update.
41+
42+
5. Update CHANGELOG
43+
44+
Add a new section with:
45+
46+
Version number
47+
48+
Release date
49+
50+
Bullet points of changes
51+
52+
Security or dependency notes, if applicable
53+
54+
6. Commit the Release Changes
55+
56+
Make one single commit for the release prep:
57+
58+
git commit -am "1.0.0"
59+
60+
7. Compare Composer Lock Files
61+
62+
Install composer-lock-diff globally if not already:
63+
64+
composer global require io-digital/composer-lock-diff
65+
66+
Compare:
67+
68+
`git checkout <previous-release-tag>`
69+
`git checkout release-<VERSION> -- composer.lock`
70+
`composer-lock-diff --md`
71+
72+
Save the markdown output for your PR and GitHub release notes.
73+
74+
Clean up your local repo afterward:
75+
76+
git reset --hard
77+
git clean -fd
78+
79+
8. Push and Open a Pull Request
80+
81+
Push your release branch:
82+
83+
git push origin release-<VERSION>
84+
85+
Open a PR:
86+
87+
Title: # <VERSION>
88+
89+
Base: main
90+
91+
Summary: Include changelog notes and composer diff
92+
93+
9. Merge Release PR
94+
95+
Temporarily enable merge commits in GitHub settings.
96+
97+
Merge the release PR into main using a merge commit.
98+
99+
Disable merge commits again afterward.
100+
101+
10. Back-merge to dev
102+
103+
Merge the changes from main back into dev:
104+
105+
`git checkout main && git pull`
106+
`git checkout dev && git pull`
107+
`git merge main`
108+
109+
Reset composer to dev mode (if applicable):
110+
111+
composer require su-sws/vpge_profile:dev -W
112+
composer update -W
113+
git commit -am "Back to dev"
114+
git push
115+
116+
11. Create a GitHub Release
117+
118+
Go to Releases > "Draft new release"
119+
120+
Tag: 1.0.0 (new tag)
121+
122+
Target: main
123+
124+
Title: Version number
125+
126+
Description: Paste changelog and composer-lock-diff summary
127+
128+
Mark as pre-release if necessary
129+
130+
Click Publish release
131+
132+
12. Deploy Artifact to Acquia
133+
134+
Checkout the release tag:
135+
136+
git fetch --all
137+
git checkout <tag>
138+
139+
Run deployment:
140+
141+
blt deploy
142+
143+
When prompted:
144+
145+
Create a tag? Yes
146+
147+
Commit msg: leave blank
148+
149+
Tag name: <date>_<version>
150+
E.g., 2025-04-10_1.0.0
151+
152+
13. Deploy in Acquia Cloud UI
153+
154+
Open the Acquia Cloud Dashboard for VPGE.
155+
156+
Click the "Code" icon next to each environment.
157+
158+
Choose the tag you just created and click Deploy.
159+
160+
Acquia will handle DB updates/config imports automatically.

‎.github/VPGE_UPDATE_PROCESS.md‎

Lines changed: 74 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,74 @@
1+
# VPGE Drupal Site Update Process
2+
3+
This document serves as a guide to updating VPGE site, blending practical steps with higher-level technical considerations. It aims to support SWS developers in managing upgrades across local, staging, and production environments while maintaining stability, test coverage, and developer clarity.
4+
## Purpose
5+
6+
This document is a comprehensive guide for updating Drupal sites maintained by **VPGE**. It synthesizes hands-on update steps with technical and architectural recommendations to ensure each site upgrade—from local development through deployment—is stable, testable, and maintainable.
7+
8+
---
9+
10+
## 1. Install the Site Locally
11+
12+
### Steps
13+
14+
- Clone the site repository.
15+
- Run `composer install`.
16+
- Import the database (from Acquia or backup).
17+
- Run database and config updates:
18+
```
19+
drush updb -y
20+
drush cim -y
21+
```
22+
23+
## 2. Assess and Pull Downstream Changes
24+
25+
> **VPGE** uses a downstream profile like stanford_profile, you’ll want to sync updates:
26+
27+
1. Remove the current profile directory: `rm -rf docroot/profiles/custom/vpge_profile`
28+
2. Clone and pull updates from the canonical profile: `git pull https://github.com/SU-SWS/stanford_profile.git 11.x -X ours --no-edit`
29+
3. Run `drush cim -y` to integrate any config changes from the updated profile. For **VPGE**, please make sure you have any config changes are duplicated and/or applied to the /config/split directory. .
30+
4.
31+
32+
## 3. Update stanford_profile and dependencies
33+
34+
In the project root composer.json, update the reference to stanford_profile to use the appropriate dev branch or 11.x-dev.
35+
1. Run `composer update -w` or `composer update su-sws/stanford_profile -W` to only update the profile.
36+
2. Add the dev version of the VPGE profile to the composer json in project route.
37+
2. Commit and push changes. Create a PR from this branch.
38+
3. Recommendation: Standardize branch naming conventions (e.g., update/drupal-11) and PR titles ([Update] Drupal 11 + Profile Changes) to improve clarity across teams.
39+
40+
## 4. Audit VPGE Modules and Custom Code Updates Use Upgrade Status
41+
1. If not installed: `composer require drupal/upgrade_status --dev`
42+
2. Visit `/admin/reports/upgrade-status` to assess module readiness, deprecated code, and unsupported projects.
43+
3. Follow the steps to update custom VPGE code.
44+
4. Check for any outdated dependencies: `composer outdated'
45+
5. Review patch failures; use Composer’s output to remove fixed patches or address changes upstream.
46+
6. Use PHP Codesniffer to review custom theme, modules and PHP:
47+
48+
phpcs --standard=Drupal,DrupalPractice path/to/custom/modules
49+
50+
Or rely on Upgrade Status module’s deprecated code analysis.
51+
52+
Stack-level tip: As part of long-term sustainability, encourage teams to phase out deprecated contrib modules and rely on upstream-supported alternatives.
53+
7. If any downstream updates necessitate updates to the theme, update npm. Review to see node --version needs updating.
54+
55+
## 5. Push code to intiate a code review.
56+
Push, Review, and Test in CI/Remote
57+
Steps
58+
59+
Commit your changes, including:
60+
61+
Composer updates
62+
63+
Config exports (drush cex -y)
64+
Test-related YAML updates
65+
Push to GitHub and open a PR for review.
66+
67+
Use Acquia’s Dev/Stage for integration testing:
68+
69+
Sync latest DB to dev environment
70+
71+
Run visual regression tools like Backstop.js
72+
Ensure all tests pass before merging.
73+
74+
Technical recommendation: Integrate Nightwatch tests or Cypress for critical path UX flows (e.g., login, form submission) and ensure they run pre-deploy.

0 commit comments

Comments
 (0)