At The Jibe, it is rare for a single developer to take a project from start to finish on their own. We’re a very collaborative bunch.

First, with more hands a project gets turned around quicker – great for our clients. Second, we like to build redundancy on every project: this helps us mitigate the downsides of working on multiple deadlines, vacations and sick days – great for our sanity. Three, we have a wide range of skills and perspectives which allows us to deliver smarter solutions – great for everyone!

A few months back when we kicked off our first LemonStand project, we weren’t sure on how to best collaborate as a team using this platform: after all, each vendor comes with its own quirks and best practices. However, after much experimentation and deliberation with the community, our multi-developer workflow was born!

Step 1: Git

While this is not specific to a LemonStand project, we like to have all of our code in version control. We maintain two global branches: master for the code that is on the live site and develop where developers can merge in their new features for testing. Developer’s then create personal branches, otherwise known as feature branches, for new features they are working on.

,

Git branching strategies - While we won’t be diving into git best practices here, A successful Git branching model is a great introduction on how to best use Git in a team environment.

,

Step 2: Theme setup

For every website theme, we maintain one live instance and one development instance for every developer. This gives developers an environment to safely develop and experiment with new work without impacting the live site. But why not a single dev environment that all developers can share? If you have multiple developers using LemonSync (we will touch more on this next) to push and pull files from the LemonStand instance, you can potentially pull down changes from another developer that would override something you have in progress.

The screenshots below show what our two developers would see when they are logged in to the backend. The live instance of the theme remains active, therefore, website visitors will not be impacted by any features that are still in development.

Developer #1 would see:

Developer #2 would see:

,

Step 3: LemonSync Setup

LemonSync is a command line tool that will watch for local changes to your theme files and then automatically push them up to your LemonStand theme. This helps you preview theme updates as you make them without have to manually upload files to through LemonStand. Read more about Lemonsync.

Each developer needs to create their own API key. It is the ownership of this API key that links the user to their editing theme. Meaning, when you, [email protected] create an API key, that API key now knows which currently editing theme to update.

Then each developer configures their LemonSync file to use their API key.

,

website-leah-lemonsync.cfg

[api] api_host = https://website.lemonstand.com api_key = K0rfPuglgHhjpOkw2WhDAYYHD3TMccg6WIOGfXnc api_access = b7YH05v19mtZEScG0cVLE44pJOuOdQaqunXUNAJF [dir] watch_dir = /leahs-local/path/to/site file_patterns = [ "*" ] ignore_patterns = [ "*.tmp", "*.TMP", "*/.git*", "*.DS_STORE", "*/node_modules/*", "*/.sass-cache/*" ] [store] store_host = website.lemonstand.com ,

website-erik-lemonsync.cfg

[api] api_host = https://website.lemonstand.com api_key = 8qPS0ZBEyysbdq2mKYygaUmbc8trF9nbHscI0jf6 api_access = rxTgVTLk4OgC6wM0gJRC30wYgBkXG1d1fGO87ehX [dir] watch_dir = /eriks-local/path/to/site file_patterns = [ "*" ] ignore_patterns = [ "*.tmp", "*.TMP", "*/.git*", "*.DS_STORE", "*/node_modules/*", "*/.sass-cache/*" ] [store] store_host = website.lemonstand.com ,

Finally, when a developer starts the LemonSync script they will be provided with messages that let’s them know what theme they are editing:

,

Terminal

$ lemonsync --config website-leah-lemonsync.cfg LemonSync is listening to changes for coastal-dev-leah in /leahs-local/path/to/site ,

Step 4: Merging features and updates

Let’s say that Developer #1 was working on the theme templates to customize the data that is being output. Developer #2 is working on the styling with CSS. At this point, because the two developers are using separate development environments, Developer #2 would not see the template updates Developer #1 has just completed. This is where Git comes in! When Developer #1 completed their changes, they will commit and push those updates to the git repository. Developer #2 can then pull down those changes. When Developer #2 does this, their instance of LemonSync will detect the new or updated files and push these to their development site.

Step 5: Releasing to the Live site

So your new feature is ready, the client has signed off and you are ready to upload to the live site.

Step 5a:

Each developer merges their new code to the stable git branch. From this point on, let’s say Developer #1 is responsible for this feature release.

Step 5b:

Developer #1 will run LemonSync and checkout the stable git branch. At this time, all code in the stable branch will be pushed to that developer’s development theme. Developer #1 takes one last look to ensure everything is okay.

Step 5c:

Developer #1 stops LemonSync and then logs into the LemonStand site and changes their currently editing theme. Remember, the API key Developer #1 created is aware of which theme they are currently editing.

Step 5d:

Developer #1 starts LemonSync again. At this time, LemonSync will ask you if you want to override your local files.

,

Terminal

$ lemonsync --config website-leah-lemonsync.cfg The above remote files have changed! Do you want to overwrite your local files? Type [Y] to overwrite your local files or [q] to quit. Any other key will result in your local files remaining the same. :Y LemonSync is listening to changes for coastal-live in /leahs-local/path/to/site ,

You should answer “Y” or yes to this. This download all of the files that are currently on the live site. This will essentially undo all the new feature updates you just worked on -- but don’t worry, Git still knows about your changes.

Step 5e:

Now, let’s use Git to get our changes back. First we will check the Git status which will show us all the files that were updated for this feature. Let’s also pull up a log of the latest commit which will show us the last commit id and message.

,

Terminal

$ git status On branch stable Your branch is up-to-date with 'origin/stable'. Changes not staged for commit: (use "git add ..." to update what will be committed) (use "git checkout -- ..." to discard changes in working directory) modified: partials/layout-head.htm $ git log --oneline -n 1 fc2cb1c Updates to head ,

This tells us that the only change for this new feature was made in partials/layout-head.htm.

To get our new feature updates back, we can either checkout the file as the Git message suggests or reset the branch to the latest commit. The second method will be better when you are dealing with many files.

,

Terminal

$ git checkout --partials/layout-head.htm ,

Terminal

$ git reset --hard fc2cb1c ,

Now all of your files will be reverted back to include all the code associated with your new feature. With LemonSync listening for file changes and uploading to the live theme, your launch is now complete!

Step 5f:

Developer #1 now goes back into the LemonStand site and changes their currently editing theme back to their dev instance. An important step as we do not want to accidentally update the live site the next time we run LemonSync.

Tell us about your workflow

As we get better acquainted with what works best for our team, we would love to hear more about your best workflow practices.