Here at Shockoe, we work on a variety of applications for clients around the world, so it’s not uncommon for our developers to work on more than one project at a time. It’s pretty standard that everyone, at some point or another, is involved in multiple builds for multiple devices. Multiple builds for multiple devices can get unwieldy, so we have crafted a few solutions to help keep our development smooth and efficient.

We supercharged our mobile workflow by:

 

1. Building a system to distribute our apps

Shockoe created a system for the app teams, including clients and mobile testers, to download and install the app right on their phones. But this isn’t enough on its own. Developers love to automate things, so along with our distribution system, we have been using Jenkins to automate the process of building the apps and uploading them to the website.

2. Using Jenkins to automate builds

We updated our Jenkins continuous integration system to automatically put new builds on our app distribution system whenever developers push new code. We needed a continuous integration system that was easy to maintain, but powerful and flexible enough to handle all of the projects we work on at any given time.

3. Using Gulp.js to automate building apps

The next hurdle we faced was being able to build a wide array of different mobile platforms and frameworks without overwhelming our developers. Every platform has its own unique build process. At Shockoe, we’ve started using Gulp.js to handle building each project, understanding that each coding language has its own set of unique requirements. Gulp acts as a task runner to allow developers to define and run repeatable build steps using Node.js. Gulp allows us to reuse a lot of code between different platforms, and it makes tracking down any build errors much easier because we know exactly which step failed. Using Gulp for our builds also means that the build process is portable. Any of our developers are able to perform builds and upload the apps in the event that our Jenkins computer ever stops working.

4. Automating the building and deployment of our solutions onto remote servers

After the process of building and deploying apps was finished, we moved on to automating our web projects. This was more straightforward than building an app. Again, we leveraged Gulp to remotely connect to the server that hosts the site, pull any new code changes, and finally build the site again. Automating this process also cut down on the number of errors made when deploying a site, thus avoiding simple mistakes like using a test configuration in a production environment.

5. Running automated tests and reporting the results

Earlier, I mentioned that part of the build process includes running automated tests on our projects. Jenkins has many tools and plugins to simplify this process. There are plugins to automatically launch an Android emulator or an iOS simulator when the tests start, and to close it after all the tests have finished. We chose Appium as our automated testing framework. Appium tests can tap, swipe, and type inside apps automatically. Automating the testing process makes it easier to test our solutions more often and more consistently. Each project in the Jenkins dashboard has a section for the test results of every build. This means you can see which changes were made in a build and whether those changes affected any of the project’s tests. When Jenkins does find a test that fails, it immediately notifies the team using Slack. With multiple developers often working on the same project, this step is helpful in finding bugs as soon as they are introduced.

To Summarize

By automating the process of delivering our apps to our stakeholders, we are able to iterate much more quickly on our products and cut down on the number of errors. Building our own website that allows us to control who can download our apps means we don’t have to worry about uploading our apps to different file share sites, or attaching them to an email and sending it to everyone who needs it. The flexibility of Jenkins means that our build computers can continually be upgraded or replaced if necessary. If our build is ever too slow, we can just add more computing power to our Jenkins setup.

Using Jenkins with Gulp allowed us to really speed things up. Since Gulp is powered by Node, our developers found it easy to jump right in and start extending the build process with new tasks like deploying and updating websites automatically.

The final step was to use the wide array of plugins for Jenkins to run automated tests, report the results, and notify the development team when something goes wrong. All of these steps helped our developers concentrate on what is really important: delivering a high-quality product without worrying about constantly building and sending apps.

 

Note from Editor:

If you’re interested in learning more about what our developers are using as everyday tools, check out these Blogs:

How to Document an Existing API Using Swagger

Debugging Titanium Applications using Safari Web Inspector

Kotlin: Three Reasons To Start Using It Today