# Workflow

# Communication

When working on a site with another developer simultaneously, communication is key in order to avoid trampling each others’ code, and being aware of each others’ activity on the theme.

On all projects, we assume code custodianship of a client’s site, meaning that we are responsible for maintaining the quality and integrity of the code in the themes.

This also means that we have to be informed by the client if someone who is not an Electric Eye dev makes additions/changes to a theme (e.g. external developers, apps, etc.). This will be communicated to the client in order to avoid developers/apps interfering with the developers’ code.

In order to record these interactions, as well as our own work, we leverage Git.

# Version Control Process

Our version control process follows the Git Feature Branch Workflow

The core idea behind the Feature Branch Workflow is that all feature development should take place in a dedicated branch instead of the master branch.

This encapsulation makes it easy for multiple developers to work on a particular feature without disturbing the main codebase. It also means the master branch will never contain broken code. Please read through the link above for more information, and how the flow should work.

Simply put: each theme should have an accompanying branch in Git.

As a note, all repositories should be private, and access will be specifically defined for each developer.

# Themes

Shopify’s theme system is very light and easy to learn, but requires a bit of time to understand and master. Code changes can be made to the theme by apps, and sometimes by accidentally by clients or intentionally by outside developers (but due to the code custodianship mentioned before, this rarely if ever happens).

To restate the above, these changes should be pulled in and added to git to avoid any code mismatches. This is covered below in the CLI Workflow.

# New Feature, New Theme

When working on clients sites, only work on unpublished “development” themes. ThemeKit will notify you if you are on a live theme. Don't ignore it's warnings!

When creating a new feature, an accompanying theme should be created. New themes should be copied from the most up to date on production, marked as an "EE" theme, date-stamped, and named for the feature currently being worked on.

An example for a new theme name would be:

EE - 05.20.22 - Collection Style Updates

# New Feature, New Branch

As stated above, each theme should have an accompanying feature branch in Git. This way, we can track what work was done, by whom, and at what time for each new feature/theme created.

If multiple developers are working on a project, it might be necessary to have several development themes on a site at a given time. If the features/changes on these development themes are to be launched at the same time, the themes (and their corresponding Git code bases) should be merged and tested by either the Lead, or an experienced developer once they are ready to be published.

# Deploying

When developing a theme, the developer on the project should set up the feature in the theme settings as much as possible, but in many situations clients will need to set these features up to their own liking.

Final user acceptance testing and approval should always be done by a Project Manager, and then the client themselves before publishing.

When a feature is ready to be published, the dev theme should be published as the live theme, along with the feature branch merged into master in the repository.

At Electric Eye, the Project Manager is usually the one who publishes the theme, and at that point the developer will merge their branch into master.

# Bitbucket

Bitbucket is our source code management platform of choice.

If you are a developer and are going to be committing code to the repositories, you will need to be added to the Bitbucket organization, which will give you write permissions to the projects you will be working on.

# ThemeKit

We use Shopify’s ThemeKit to make front-end development on our clients’ themes as easy and as manageable as possible.

Before running, always check that the Theme IDs in the config file corresponds with the theme you are working in. This should hedge against accidentally pushing code to a live theme, or the incorrect development theme.

The git flow detailed above should provide a backup of the most recent version of the site, should something catastrophic happen.

NOTE: when using Shopify CLI, the workflow is similar, but uses a different push/pull workflow.

# CLI workflow

This is shows a typical workflow when doing development work on a theme:

git pull to pull all theme code from a repo, to bring your repository's code up to date with Bitbucket.

git checkout -b "collection-style-updates" to create a new feature branch from master.

theme get to get the code from the theme you are currently working on. This will download any code that any errant app installs might have occurred on the live theme. If any diffs arise from this situation, they should be checked and kept/cleaned/discarded as necessary.

npm run watch (optional) Some themes leverage custom code builds (like our custom starter theme VG+).

theme watch coding begins! Coffee is consumed, heads are scratched.

git add . Usually only when you’re happy with the code you have written and are ready to commit.

git commit -m “EE - 05.20.22 - Collection Style Updates” Whenever possible, only non-breaking, working, clean code should be committed. Commit messages should be succinct but descriptive. The suggested format is the same as the naming of new themes.

git push Thou Shalt Always Push Thy Code. Make this muscle memory - whenever you commit, you push!

Now, in Bitbucket, create a pull request into master. It will either be reviewed by a peer and merged, or you can review and merge it yourself once the theme is published.

Note: ensure the .gitignore file is removing config.yml to keep the API key safe and secure.