Documentation

# Development & Release Processes

The following sections outline the processes surrounding development of this codebase, deployment of assets into the client's staging and production environments and the business processes pertaining to both. These standards should be strictly adhered to when working on this project. Contact a manager if you have a question pertaining to any point in the following documentation.

# Development

Many of the development processes follow a Gitflow (opens new window) workflow model. Familiarity with this workflow is beneficial to working with the codebase. Additionally, many of the operations related to creating feature branches, merging feature branches, creating releases and more are made simpler by the git-flow toolset (opens new window) for Git. This cheatsheet (opens new window) may be helpful in getting started.

  1. All work shall be done against a feature branch cloned from the staging branch.
  2. Add a note to the project's changelog.md in your feature branch and commit.
  3. Add a meaningful brief description of work done in the commit. If possible, add a commit-msg git hook (opens new window) to prepended task number to each git commit message. This way each commit can be correlated to each issue we are tracking.
    Note that TW # in the code refers to Teamwork, software DNL uses to track issues. The value should be changed to accurately denote each different system, so developers can reference the task in question.
  4. If deployment will be complex (i.e. many images to push to Luminate, several Pagebuilder templates to update, etc..) then maintain a list of deployment activities in the change log.
  5. Generate a review URL for client to review.
  6. Upon client approval:
    1. Merge feature into the staging branch, use git flow to finish a feature.
    2. Test the code with proxy turned on, but with feature branch URL removed. Use new private window or incognito browser to ensure you have a clean session. The goal is to test merged code for any basic errors.
    3. Resolve any issues resulted from merge, then push the code to the origin staging branch.
    4. Deploy any PageBuilder assets into the environment, if applicable.
    5. Test the code with proxy turned off, so that you are testing automatically deployed code that will go into production. Use new private window or incognito browser to ensure you have a clean session.
    6. Notify the project manager or the client and have them do the last round of testing.

# Commit Message Git Hook Code

#!/usr/bin/env python

# Updates commit message with TW ID from branch.
# Assumes branch is formatted like "bug/12345/my-fix".
# Will output something like: "TW ID#12345: I fixed it!"

import sys, os, re
from subprocess import check_output
# Collect the parameters
commit_msg_filepath = sys.argv[1]
txt_file = open(commit_msg_filepath, 'r')
commit_message = txt_file.read().strip()

# Figure out which branch we're on
branch = check_output(['git', 'symbolic-ref', '--short', 'HEAD']).strip()

# Print TW ID from branch name:
m = re.search('(([0-9]+[^\/]+)\/)', branch)
if m:
    message = 'TW #' + m.group().rstrip('/') + ': ' + commit_message
    # print 'TEST: ' + message
    with open(commit_msg_filepath, 'w') as f:
      f.write(message)
else:
    print 'No branch with naming was found.'
sys.exit(0)

# Releases

Releases will be performed at the client's request. The process for creating and deploying a release is as follows.

  1. The STC team notifies team DNL when the released is planned.
  2. On the day of launch, STC send the final message of approval with a list of approved tasks.
  3. Team DNL does a release using Gitflow, tests the deployed code and notifies the client of completion.
    1. Create a new release branch.
    2. Perform any minor documentation updates and/or minor bug fixes.
    3. Update the version attribute in package.json.
    4. Update the changelog.md.
    5. Merge release branch into master, create tag for the release (git tag -a v{version} -m {version}) then merge release branch into staging.
      Note: the Gitflow command git flow release finish {version} automates these steps.
    6. Push both master and staging branches to the repository as well as the new version tag (git push origin --tags).
    7. Confirm that the push to master triggered an automated deployment and that the deployment was successful.
    8. Run automated test suite, if applicable.
    9. Perform manual Q/A to confirm presence of the new features/fixes (ensure that development proxy is off).
  4. If any issues are discovered during the release, the hotfix is created and deployed to remedy the issue and ensure smooth operation of the site.

# Page Rendering

The site was created with static php files originally as a prototype, the code was then moved into Luminate and AEM. The static site can still be viewed. The more complex Luminate pages use PHP to stitch together various PHP files, so must be rendered through the PHP server first.

This code base has been configured to work with Lando to render a static PHP site.

  • Install Lando on your machine
  • Then from the root directory, start Lando with command lando start
  • View $landoDomain in the browser, where $landoDomain is replaced by the domain Lando renders in the console

← Change log →