Technical Overview: Github, Pantheon#
NPL-D8 project workflow allows multiple developers to work on site features simultaneously without conflict.
Git Branches#
- Feature branches are where we do work.
- Develop branch is where we collect features to prepare for a release.
- Master is the stable release branch.
Workflow Overview#
- Developers use git flow to crate feature branches.
- Work is done on the feature branch then pushed to Github where CircleCI creates a Pantheon multidev.
- Work is tested on the multidev. If the multidev looks good, developer creates a pull request in Github.
- Work is reviewed in Github and, if approved, it is merged into develop.
- Develop is then merged into master which is pushed up to Github. Github does the build and deploy to get changes to Pantheon dev.
- Work is reviewed on Pantheon dev and test before being deployed to live.
Key Items for Building the Workflow#
-
Github > SSH Key for Pantheon AND CI user in Pantheon
- This is a fragile point in the workflow. Currently, ci@atendesigngroup.com has to be a developer on the Pantheon project. If the user is removed from the group in Pantheon, then all of CircleCi will break (pushing code will break). We can swap out that user to an NPL email if we want.
- If we move to an NPL ssh key, we’d need to update that in the .circleci > config.yml file in two places.
-
GitHub Actions > .github yml files
- We have three GitHub actions yml files, which replace CircleCI.
- One file builds the multidev after a pull reqeust is created.
- One file deletes the multidev after the pull request is merged into develop.
- One file deploys code to Pantheon Dev.
-
Pantheon YML Configs > pantheon.yml
- Pretty bare bones.
- Telling what happens after a deploy and after a code sync.
- Calls a file called afterSync.php
- All documented on Pantheon for this thing called Quicksilver, which was used for the afterSync.php code.