Sparkbox Iterative Drops Process
Sparkbox has put an immense amount of time, thought, and effort into its website and web app build process. By gluing powerful tools like Grunt, Sass, Yeoman, Ember, Knockout, and others together, we are able to frequently deliver increments of a website/app for integration and feedback with a final hosting environment.
We’ve found the following process to ease the handoff and integration of each increment where technologies often collide. This is a model most appropriate when Sparkbox is not involved in the final CMS integration.
Sparkbox makes every effort to follow the Github Flow, keeping
master as clean as possible and ready for delivery. Our commits attempt to follow a common pattern, and we make every effort to ensure code reviews happen in all cases. Each of these is meant to help with collaboration within our team and with delivery to our clients.
As soon as the website build is underway, we’ll work with the integration team to coordinate a weekly or twice-weekly integration meeting. Commonly held Monday/Thursday or Tuesday/Friday, this meeting has two parts:
Integration Review is an opportunity for the integration team to demonstrate the current state of what has been integrated. All efforts are made to do this in a shared environment, such as a Development, Test, or QA server. In most cases, this is a formality, but at times, we may catch design elements that haven’t integrated appropriately.
Each Integration Review will include a new Drop containing completed features or changes. A drop consists of both a Github Release and Github Issue to track the integration.
Github Release contains a compressed version of the built website called dist.zip. Github Releases inherently create a Git Tag that we use in the Issue that is linked in the release description.
Github Issue will detail the Handlebar’s templates that have been changed for this drop as subtasks. We’ll often include notes about the type of changes that we made to help integration find changes or new templates.
Also included is a link to view the differences between the previous Release Tag and this new Release Tag. This can be really helpful when a drop includes refactorings or other changes that might be challenging to translate.