The game ascended the Top Downloaded charts worldwide almost immediately, reaching #1 in the US on iPhone the next day, thanks in part to a massive, multi-channel launch campaign that included publicity stunts in both New York and London, a saturation initiative on Facebook that reached 100 million people in 7 countries on the first day of the launch, a TV commercial that will run in 20 countries up through Christmas, and outdoor ads aimed at commuters in select cities.Ĭandy Crush Soda Saga converted this exposure into significant revenues: as of this writing, the game is #5 or higher on the App Store’s Top Grossing overall chart in 46 countries on the iPhone (including the US, where it is #4) and is #5 or higher in Google Play’s Top Grossing overall chart in 21 countries (including the US, where it is #3). With each release, repetitive manual tasks are automated, and most importantly, we stay aware of our shortcomings and work actively to address them! So our rosy picture isn’t really too far from our everyday reality.On Tuesday, November 11th, King Limited globally launched its latest mobile match-3 game, Candy Crush Soda Saga (CCSS).
We focus on shortening the time between creating the Release Candidate and the actual release, while striking a balance between keeping up with the latest releases of the internal dependencies and ensuring that the app is always working. That’s the messy reality, but we’re always improving our release process. Sometimes, Jenkins breaks, and the builds don’t go through sometimes we’re not so great at testing all of our features before we create the release candidate, and spend the next day fixing unexpected bugs we test too many things manually every once in a while we even get a live bug that forces us to patch. It doesn’t always go smoothly, of course. This sounds good, but is this really the way it works? As with all projects and processes this is a rosy picture of the perfect release workflow, when everything goes smoothly. To ensure a continuous transfer of knowledge, and to avoid reinventing the wheel with each release, the rotation requires that one of the assignees was also assigned to the previous release, and the other assignee will be on the following release. We all do! Since our release process is not yet 100% automated, it requires a technical person to be involved, so the responsibility of pressing the buttons is rotated among the developers, with two assigned per release.
0 kommentar(er)
