How we ship software at Battlefy
At Battlefy, we encourage everyone to be heroic and bold. Our engineering team relentlessly looks for the right tools and processes required to ship fast and cautiously. That said, delivering features quickly to our users should not automatically equate to recklessness. With a small team of 6 engineers and growing (we’re hiring), we’ve been able to maintain a high level of stability throughout the evolution of our deployment process — Thanks to the amazing work of Jared Daley and Shane Jonas, we’re able to move fast and not break things.
Phase 1: Feature Complete!
Walking through the process of deploying a new feature or fixing a bug, as an engineer on a squad (ex. The Fluffy Cats, yes, that is the name of one of the squads), one would only need to submit a pull request (feature branch off of develop). The pull request would need a few things depending if it is front-end or back-end specific. For back-end specific pull requests, there would need to be a link to the JIRA ticket, tests, and a set of migration instructions (if you’re changing the models). For front-end specific pull requests, one would only need to add the link to the JIRA ticket, attach a Licecap (creates an animated GIF based on your screen) which exhibits the bug fix, and add a link to the Screener tests that were added. Screener is a the tool we use to do our automated tests which include DOM change detection and screenshot diffing on a per build basis. The neat thing about Screener is that you can import your old Selenium scripts and it is fully integrated with our existing pipeline (Jenkins), as well as, sends results to our Slack channel (#smoketests).
Phase 2: Code Review
After a pull request has been sent, at least two engineers will take a look and discuss anything that comes up. Generally, code reviews go by quickly as we tend to discuss architectural and performance concerns before coding. Once the pull request has 2 thumbs up emojis on it (or cat/dog/wolf emojis) — it gets merged into develop, which is our integration branch. Once the merge completes, Jenkins picks this up, ships the assets within our front-end project up to AWS S3, and runs tests on the develop branch and then builds and deploys a set of docker containers to a pre-production environment. At this point, we also hit the Screener API to let it know that the pre-production environment’s front-end needs to be tested. Any changes on the front-end that are detected will show up in Screener‘s reporting suite, as well as, the summaries show up in our Slack channel (#smoketests).
Phase 3: Release!
When we want to release to production, a pull request is created to merge develop into master. Once this is merged and tagged for the release, Jenkins picks this up, builds the docker images, pushes the docker images to Docker Hub, and deploys the docker images to AWS Elastic Beanstalk. If any issues arise and you need to rollback, the AWS Elastic Beanstalk UI makes it easy to rollback to the last deployment (or any deployment in the past).
Continuous Improvement
We take a lot of pride in our work and we’re all highly motivated make a positive impact on eSports — we like to call ourselves heroic, a popular term in gaming culture that represents being full of integrity, being committed to a mission, and making a difference. Gaming has become the most popular category on YouTube because people love to watch people playing games — Same goes for competitive games like League of Legends, Dota 2, Starcraft 2, and Hearthstone — eSports is on the rise. Did I mention, we’re looking for amazing people to join us in our mission?
Stay tuned for more as we have plenty of content coming around how we do feature toggling, how we version our APIs, how we do automated front-end testing, Mobile, MongoDB, League of Legends match stats with Elastic Search, Logging with ELK, Scaling NodeJS, and of course, more Docker fun!
Cheers,
Jaime Bueza
Follow me on Twitter @jbueza
Follow Battlefy on Twitter @Battlefy
Originally published at blog.battlefy.com on November 24, 2014.
