Hearst Faststore Builder – Development & CI/CD Process

1. Local Development Workflow

1.1. Running the Development Environment

What Happens?

• • yarn dev triggers the copy-files script, which runs copy_files.sh.

• • This shell script (and related watcher scripts) monitors for file changes in the configs and store directories.

• • The configs folder is structured to organize environment-specific configuration files for each store. The typical structure looks like this:

    configs/
      store1/
        dev/
          ...config files...
        qa/
          ...config files...
        prod/
          ...config files...
      store2/
        dev/
          ...config files...
        qa/
          ...config files...
        prod/
          ...config files...
    ...

• • When a file changes, the watcher script:

• • Copies the updated file into the correct location in the target store directory.

• • Detects the changed file.

• • If certain files (like yalc.lock) change, it can automatically restart the development server.

• • This ensures your local application always reflects the latest configuration and source changes, providing a seamless development experience.

Scripts Involved

• • watch_changed_files.sh (macOS/Linux) and watch_changed_files_win.sh (Windows): These scripts handle the logic for detecting changed files and copying them to the appropriate destination.

• • copy_files.sh: Orchestrates the file watching and synchronization process.

2. Build Process

2.1. Building Store Packages

• • Creates a .build directory.

• • For each store in configs, it copies the base store code from store and overlays the environment-specific configuration.

• • The result is a set of ready-to-deploy store directories for each environment.

3. GitHub Actions Automation

3.1. build-and-deploy.yml

• • Copies the relevant store configuration into store.

• • For each store:
    • • Clones the corresponding target repository.
    • • Creates a new branch, syncs the latest build, and pushes changes.
    • • Opens or updates a pull request in the target repo.
    • • Uploads a list of created PR URLs to S3.
    • • Comments on the original PR with links to all created PRs.
    • • Downloads the list of related PR URLs from S3.
    • • If the main PR was closed (not merged), closes the related PRs.

3.3. jira-automation.yml

• • Extracts the Jira issue key from the branch name or PR title.

• • Transitions the Jira issue to the appropriate status based on the PR action and target branch:
    • • dev → Review
    • • qa → UAT
    • • main → Done

• • Adds comments to the Jira issue with PR details.

• • Sends a Slack notification when a PR is merged to main, including PR and Jira links.

3.4. auto-update-branches.yml

• • Automatically merges changes from main into qa and dev branches, keeping all environments in sync.

Summary

• • Local development is streamlined with file watchers and automatic server restarts.

• • Builds are environment-specific and automated.

• • Multi-repo PR creation and merging

• • Jira ticket transitions and Slack notifications

• • CI (build, lint, test)

• • Branch synchronization