If there’s anything we can say definitively about building an app, it’s that the work is never completely finished. There will always be improvements to make, new features to add, or things to update as operating systems evolve. In this series’ final post, we have advice for making that continuous build and deployment process as painless as possible.
There are a lot of decisions you need to make about managing your codebase — what kind of version control are you going to use? How do you manage contributions? Who is responsible for code reviews? Who decides which changes get merged and how do you manage the release? All of this is likely to evolve as your team and your code base grows. What works for a team of four may not for a team of 60 — and vice versa.
One size doesn’t fit all when it comes to how to organize and manage your code. Multiple repos may work well; alternatively, there are also some major benefits to keeping everything in a single, monolithic repo, including simpler dependencies and organization. One size doesn’t fit all, and there may come a time when you have to make changes; expect that to happen eventually.
You’ll need to establish a release cadence on your team. How often do you cut a new release branch, and how long does it get tested before release? Are you doing feature-based releases or are you sticking to a regular time interval? Different types of cadence may be appropriate with different team sizes and stages of the product. Be careful about releasing too frequently; every time you do, you’re asking for action from all your users to stay updated. Automatic updates have made this more seamless, but you should still keep this in mind. Our Android engineering manager Jan Chong gave a great talk at Flight about how Twitter’s thinking evolved on this as our team grew.
You’re going to need to set up deploy processes, which may have many moving parts. Unlike on the web, where a deploy is more or less totally in your team’s hands, on native mobile the store affects your build process because it has update protocols and timelines you need to conform to. A native mobile deploy involves a lot of actions in sequence:
If you’re doing this, you’re probably already using multiple tools to get it all done — and that can get messy. Our goal is to simplify developers’ lives and save people time, so we were excited to announce at Flight that fastlane was joining the Fabric family.
Fastlane is an open source tool that helps you define and run deployment pipelines, or “lanes,” for different environments. You define each lane in a Ruby file called a “fastfile” that sets up a series of steps that every deploy should take. Think of it as a runbook for your deploys — it’s documentation of how things work, so everyone on your team knows what happens in an app deploy, and the code to actually deploy. You can check the fastfile into source control so everyone on the team can use it — and you can produce more consistent results.
We’ve put lots of work into fastlane because we believe in making robust, flexible tools that save us all time. Fastlane is open source and accepting pull requests — and we’d love for you to contribute! Whether you’d like to see new third party integrations or you want to build new tools on top of Spaceship, the Ruby library for connecting to Apple’s Developer Center, we’d love for you to share it with the community.
That’s all we have for our blog series — but the conversation can keep on going! Tweet using #MobileAppPlaybook to share your knowledge with the rest of the world.
Did someone say … cookies?