Release your iOS App with just One Line Slack Command
By: César Vargas Casaseca
Tags: Slack, Continuous Integration, App Development, Software Development, iOS

Release your iOS App with just One Line Slack Command

A journey from Slash Commands to Fastlane

In WELT we rely heavily on our Continuous Integration implementation. We use it not only to compile the code and run unit tests to ensure a valid app status at any time, but also deliver our product to TestFlight. Besides creating a new build automatically each time a new feature is merged, we can trigger those whenever a new release is requested. Automatizing this step we are sure that no human error spoils the process, as might happen when building and uploading manually from Xcode.

Given the expense of maintaining a local CI Server such as Jenkins, we moved to Travis CI, a hosted solution where all that functionality is included in their paid plan. We configure our tasks by adding a file named .travis.yml , which is a YAML format text file, to the root directory of the repository. This file specifies the programming language used, the desired building and testing environment (including dependencies which must be installed before the software can be built and tested), and various other parameters. (Wikipedia) Thanks to that we can select and change the Xcode version by only changing one line of that file, skipping all the hassle that it used to involve in Jenkins. In our article we will thus use Travis, but the same process can applied to any CI Platform that accepts jobs triggering via their API.

Every time a new push is performed in our GitHub repo that file is read and the configured action triggered. Following that, we arranged that whenever we push in a branch with the prefix release, a new Build is created and delivered with the content of that branch.

That is relatively easy to perform for us developers, but what about QA, Product Owners and other stakeholders without access to our repo? Wouldn’t it be awesome if they could do it every time they want a new build without having to tell us? Wouldn’t it be nice that we make that even easier for us? Travis allows the triggering of a Build via their API, but we still need to trigger that in a way that is easily accessible for all the members of our team. This is when Slack comes into play.

Since Slack is our favourite medium for communication, we chose Slash Commands to do that. Slash Commands allow you to listen for custom triggers in chat messages across all Slack channels. When a Slash Command is triggered, relevant data will be sent to an external URL in real-time.

Ok, we can call an URL, but this we are very far away to trigger a release. We need an intermediate Server Application that receives the URL call, checks that the right credentials are there, extracts the requested parameters and convert them to execute the triggering script through the Travis API. Once the job is launched, it will use Fastlane — as usual — to build and deliver.

We are almost setup, but we still have to choose the right technology for our Server App, and where to host it. Although still in an early stage, I opted for Swift Vapor to implement it. Vapor is a web framework for Swift, that provides a beautifully expressive and easy to use foundation for a website, API, or cloud project. As a Swift Developer, getting deep into Vapor was something I yearned to since its release, and this simple project was the perfect sandbox to try it. It is like a dream being able to use the same language I use for iOS apps in the server! In our Native Development Team at WELT we use Kotlin for our backend Spring Boot App and the Android App, so I was a bit “jealous”. Now it is time for my revenge!

Given its straightforward and smooth deployment, it would be hosted and run in Heroku.

In conclusion, we will: