If you want to build a solid maintainable app, you need to have a repeatable build and automated testing. All our projects are run with automated tools. The point of the automated tools is letting everyone know when something goes wrong, so that it can be fixed as early as possible and ensure that critical errors don’t make it through to the customer. Every Continuous Integration (CI) tool provides a dashboard to ensure that consistent feedback. At Seventh Beam we’ve taken it a step further and integrated the build process into our office fixtures.
We’ve added a LIFX bulb into our CI stack. The light goes cyan when a build starts, letting everyone know when a build is on its way. Then when all goes to plan it switches to green indicating a successful build, and a happy team. When the light goes red there is an issue, informing the team so that they can get to the bottom of the issue.
Our standard build stack
IDE
We mostly use the standard IDEs – Android Studio for Android and Xcode for iOS. I’m also partial to using AppCode for iOS development. A lot of this is a comfort thing, I have 5 different Jetbrains IDEs installed at the moment and jump between different languages and tasks. Having a consistent IDE helps me be productive.
Source Control
We run our own Gitlab instance in the cloud. This gives us the flexibility we need to keep everyone productive, while allowing us to give customers access to their and only their source. A couple of the key features in a source control system are management of merge requests, good code review tools, and the flexibility to implement your own processes.
CI/CD
We have our Jenkins installation locally in the office but found the managment overhead of this system was becoming a problem, so we moved to a cloud service named Bitrise. Bitrise is a really powerful build tool which we have configured to build on each Pull Request (on creation and on merge), run unit and instrumentation tests, sign the builds, and when appropriate push the apps to the appropriate store.
App Distribution
Again we stick with the standard tools here – TestFlight for iOS and Google Play for Android. We set them both up with Alpha (internal), Beta (stake holder) and Gold (customer) builds that we automatically deploy through the levels. Automating this process is important; human error with a manual process potentially causes many issues.
Crash Tracking
We love the Firebase tools for a lot of the production maintenance components. We almost always integrate Firebase Crashlytics, to keep track of app crashes. If you include Firebase Analytics to get a sense of how your customers are using your app, Crashlytics is able to use the Pageview analytics to provide bread crumbs leading up to a crash. Understanding the journey your customer took through the app before it crashed can lead to helpful insights when trying to find those mysterious crashes. When you come across a piece of code where you are catching an exception with a comment like //Code should never get here you should log this up to Crashlytics as a non-fatal. If it should never get there and does you need to know about it.
Crashlytics.sharedInstance().recordError(error)
About the Author
Jeff Smith – Co Founder / CTO – Seventh Beam
Has a preference for things in 2. 2 Kids, 2 Legs , 2 Banh Mi , 2 Wheels
