Image credit: Carnegie Mellon University
 At Mission Data, we’re always looking for ways to better serve our clients. When we start working with them, we explain how we generally adhere to agile methodologies to continually make sure we’re meeting their needs at every step in the development process. Over the years, we’ve gotten pretty good at the communication side of serving our clients. But we can always get better.
The industry has recently started looking toward automation in search of better methods for delivery of digital products. Some of our associates representing development, design, operations, and quality assurance have been working to find opportunities to add value to our process through automation. Continuous integration and continuous delivery are only a few of the techniques that we’re using to improve delivery for clients. This enables us to spend more time solving business problems, and less time doing repetitive portions of our work.
Continuous Integration (CI) is a process by which we develop and verify new features into a project. Verification is done through series of tests developed and written in parallel to the traditional software development lifecycle. These tests are run with every change that is made to the source code repository in an automated way, and as a result frees up developer time.
Continuous Delivery (CD) builds upon the CI concepts by deciding what to do with the code once everything is in appropriate order. When the CI tests run, the results simply return either pass or fail. If a test fails, we have a developer re-evaluate the code produced and feed it back into the cycle. If all tests pass, we have a number of options available to us. For web applications, we can automatically have the project delivered to staging servers for review. For compiled applications, such as iOS or Android, we often push the resulting app to a platform specific distribution service to make it reviewable on real devices.
A few years ago, we moved our code storage and versioning to GitLab. GitLab recently released a CI platform to go along with their repository management system. Being long term users of older CI systems like Jenkins, we decided to give GitLab’s CI system a try in hopes of a more integrated system. We started with a few of our Ruby on Rails projects and followed that up with some of our Android and iOS projects. We found that the tighter integration between GitLab and GitLab-CI made the job of setting up CI for a project easier and as a result we have ended up making it almost mandatory for all our projects. Handling the builds and having GitLab-CI send them to our customers cut almost an hour off each feature development cycle. With us doing multiple features each week, this started saving us and our clients a lot of time.
Now that we’ve had some quick successes, we’re looking for more ways to use our burgeoning CI/CD stack. Soon we’re going to start letting the system deliver web application and API updates automatically to staging sites for review and eventually to the production servers. We already have systems that we’ve been using for years to reliably deliver our web applications on demand. With these tools and systems in place, there’s no reason that process can’t be leveraged by the CI/CD stack.
Submitting mobile apps to the Google Play Store and Apple App Store is a very time-consuming task, and the process of doing so can be interrupted for the smallest of reasons. With the automation we have now, the final process for a production build is to upload the build to the appropriate store and hit submit.
The possibilities that automation offers are extremely exciting. The automation of repetitive work allows us to focus more on the business problem our software will solve. We have been proponents of CI/CD for years and the above is an overview of our ever evolving philosophy.
