“Working software is the primary measure of progress.” This is one of the principles of Agile methodology and one of our work principles as well. We make sure any code commit may be released to clients at any point. Tracking progress helps us stay focused on our goals and to stay on the same page with clients. We apply a continuous delivery approach for the following reasons: accelerated time to market, a chance to build a quality product, process automation, and increased reliability.
By promoting source code from one environment to the next (from development to quality assurance to production), we can rapidly deliver business value to clients.
We build software in such a way that it can be released to production at any time. Let’s assume, for instance, that we’re building a social app that has a number of features such as user authorization, messaging, social sharing, commentary, and push notifications. Once a particular feature – messaging, for example – is built, reviewed, and tested within a single iteration, it can then be deployed to the production environment.
Every new update that extends existing functionality or brand new feature is worked on within its own development branch. Once an update or feature is fully functional, this separate development branch is merged into the stable development branch. Next, the source code is pushed to quality assurance for testing, and from there deployed to the production environment.
Our workflow typically looks like this:
A weak production deployment can ruin all the effort invested in a development process. Our solid deployment workflow is one of the greatest assets of the BioCard team.
One of the principles of continuous delivery is continuity. Get the work done and go home isn’t how we work. We need to deliver new features constantly to stay in the game. The ability to continuously adapt software based on client’s feedback and business changes, and to submit builds with minimal disruption to our clients are the bases for building a quality product. That’s why each iteration at BioCard wraps up with a presentation of the tangible result of our work in the form of a build and a demo.
At the end of each iteration we deliver a build to the client. The goal of the build is to show the team’s progress and get client feedback.
We also deploy so-called intermediate builds in case there is a need to show progress on some of the most vital functionality that might require instant fixing in the middle of an iteration. Intermediate builds make the app development process even more transparent, since a client can see the improvements we’re constantly bringing about.
Along with build delivery, we also provide clients with project demos or an online presentation of the latest build. A demo is prepared and performed by the development team. It helps us emphasize the most important changes, demonstrate functionality and improvements made during the last iteration, and visualize the project development progress.
The build is usually launched on a developer’s laptop with the help of an emulator or a simulator. We use the emulator from Android SDK and the Genymotion emulator for Android, and the Xcode simulator for iOS. In some exceptional cases (for example, when a client is not available for an online chat), we can record a demo using a screen recorder like Screencast.
Frequent build and demo deliveries help both the development team and client make sure that they are on the same page, and that a project is following its development path. This process all boils down to recording the results of our work. Documentation is critical to quality control and team communication.
We use automatic triggers in the process of continuous delivery to significantly save time for developers, testers, and clients. In this way we cut down on manual tasking, improve our productivity, and provide greater reliability.
We deliver builds using Continuous Integration (CI) processes, which means automatization of code reviews, code merging, build assembly and build delivery to all the participants of the development process, including the client.
For each platform we have separate CI servers – Xcode server for iOS, and Jenkins for Android – that automatically assemble builds after new code has been merged into production.
The build servers are integrated with Crashlytics crash reporting and Crashlytics Beta distribution services. Crashlytics crash reporting gathers all information about crashes and sends reports back to the developers so that they can fix the issues; Crashlytics Beta distribution is used for build deployment.
Crashlytics Beta allows us to create various groups (e.g. developers, testers, and customers). In this way the client – i.e. the “customer” group – always has access to the latest build without bugs.
When a build is assembled, it’s included into a corresponding project and group in Crashlytics Beta, and an email notification is sent to everyone connected to that group. The email contains a link to download the build. After downloading, the build can be installed as a regular application on a mobile device (and each subsequent build will be installed as an update).
To optimize the process and prevent our clients from wandering between old and new functionality, every build is supplied with release notes explaining changes and new features added in the current build.
Continuous delivery allows us to minimize risks associated with a release and achieve greater reliability. Our workflow lets us test code repeatedly, find and fix problems more easily, and reduce the impact of major bugs. (time)
Accelerated time to market, building a quality product, process automation and reliability greatly improve the level of customer satisfaction.