Ship.io Getting a Commercial Release: Continuous Delivery for Mobile Development

Ship.io, a SaaS that promotes Continuous Delivery for native mobile applications, is going to see a commercial release with Electric Cloud. This announcement follows a recent and successful beta run of the automation platform for building, testing, and deploying, which featured 6,000 users.

The partnership between Electric Cloud and Ship.io makes a lot of sense, and it's coming to a market that will likely make serious use of its services. We at DZone have been no strangers to the virtues of Continuous Delivery, and a big takeaway in the last year has been not only the fact that CD is extending into mobile environments, but that mobile applications need special attention to automate and deploy natively.

Ship.io is coming into a mobile app marketplace of 3 million apps and nearly 5.5 million developers. Mobile application development has typically required its own platforms to meet its specific obstacles, but testing is not as widely performed with mobile apps as you might expect--some say that only 30% of organizations test their mobile apps... which is where Ship.io comes in. Ship.io streamlines the app development lifecycle, and allows developers to focus on bringing Continuous Delivery to their apps by automating the build, test and deployment processes of native iOS and Android apps.

Here are a few of the features with Ship.io:

Ship.io Key Features

• It automatically detects and configures native Android and iOS projects to allow teams to build apps across supported OS, version and device screen types.
• Ship.io supports the latest tool chains, languages and OS releases, including GitHub, Gradle, Xcode 6.3, Swift, iOS 8, Crashlytics Beta, HockeyApp, as well as Slack, HipChat and various web hook integrations.
• It connects existing tool chains to simplify and automate unit, functional and physical device testing (using AppThwack for iOS devices), and allows teams to run tests every time code is committed for fast feedback.
• Centralized dashboards provide visibility into all build, test and deployment status levels, and supports cross-team collaboration and historical reporting.

How does Ship.io store my Developer Certificates and Provisioning Profiles?

Developer Certificates and Provisioning Profiles are used to sign iOS builds so that they can be installed on devices for testing. When uploaded to Ship.io we immediately encrypt the files, before they ever touch a disk, using a combination of 2048-bit RSA and 256-bit AES encryption and store them securely in an access-controlled repository. Once encrypted, the files can only be read by our build servers and are only ever decrypted long enough to sign the build, after which time they are immediately destroyed.

What changes does Ship.io make to my repository?

• In cases where your Github account has access to make changes to the repository we'll setup aWeb Hook, that's it.

What does Ship.io do with my code?

Here at Ship.io we understand how important your code is and keeping it safe is our highest priority. When your code is pulled down to our servers to run a build the transmission is always encrypted. As soon as the build is complete, no matter success or failure, the code is immediately deleted. Finally, we'll never look at your code unless we're assisting you with a problem and you have specifically given us permission.

For more information see ourprivacy policyandterms of service.

How does Ship.io sign Android APKs?

Similar to Apple's system, which uses Provisioning Profiles, Android requires that all application files (APK's) be signed with a keystore before they can be installed on a device. Keystore's come in two flavors:

1. Debug Keystores: These keystores are used only for development. APK's signed with a Debug Keystore cannot be uploaded to Google Play and require that end users who install the application turn on the "Unknown Sources" setting (see how).
2. Release Keystores: These keystores are used to sign the production version of your application so that it can be uploaded and distributed on Google Play.

You can upload either keystore-type to Ship.io from the Code Signingpage and choose the keystore when creating your build step. However, you can also choose to have Ship.io generate a debug keystore when creating your build step for simplicity (if you don't intend on publishing the generated app to the Google Play). Go to the Android build step help page for more details.

The important points to understand about signing Android applications are:

• All applications must be signed. The system will not install an application on an emulator or a device if it is not signed.
• To test and debug your application, the build tools sign your application with a special debug key that is created by the Android SDK build tools.
• You can use self-signed certificates to sign your applications. No certificate authority is needed.
• The system tests a signer certificate’s expiration date only at install time. If an application’s signer certificate expires after the application is installed, the application will continue to function normally.
• You can use standard tools – Keytool and Jarsigner – to generate keys and sign your application .apk files.
• After you sign your application for release, we recommend that you use the zipalign tool to optimize the final APK package.

How do I make sure my project will build using Ship.io?

Setting up a build environment can be a time consuming and tricky process. Here at Ship.io, we abstract this complexity away so that developers don't have to worry about those details. That means that our build environments have been designed to support the widest range of mobile application configurations while also ensuring all of our users' data is handled securely. Achieving these goals means that some things which are possible in a dedicated server environment are not supported on Ship.io. Here is a short list of recommendations that will help your team get the most value out of Ship.io:

• Git Submodules: Ship.io has no problem pulling git submodules. However, it's important that our system have access to pull them at build time. While we can automatically configure access to your git repository you may need to manually configure access to any private submodules that your project uses.
• 3rd Party Frameworks/Libraries: It's important to include any 3rd party libraries or frameworks in your source code repository so that they are accessible during the build process. For Open Source frameworks this can usually be accomplished with the use of Git Submodule's.
• Unsupported Test Frameworks: Please see the above list of supported Unit Test frameworks. Test projects developed using other frameworks will not run correctly on Ship.io.
• Shell Scripts: When creating your job configuration, you can choose steps such as building the application, running tests, or even custom shell scripts.
• iOS SDK Version: When creating an iOS job, be sure to select the correct SDK version. Some projects require that they be built again the device SDK. When creating or editing your job look for the option titlediOS SDKto modify this setting.

If these limitations are a deal breaker for your organization pleasecontact usto discuss a dedicated server plan.

How are builds triggered?

After creating a job, the job can be triggered to create a build in three ways.  1) manually by clicking start build in our web app  2) through commit hooks if selected this way (so every time a developer commits a new change it will automatically trigger) or by 3) through polling git or bitbucket if selected this way (so at a certain time interval Ship.io will check to see if there are changes in the repository, if there is then we will create a new build)

Setting up your Job with a schedule of Commit hooks is often the preferred method of triggering a build.

How do I integrate Ship.io with my own backend or web service?

We support integration with 3rd party systems by sending Notification Callbacks whenever a build completes. These callbacks are sent as an HTTP POST to a url that you select and contain information about the status of the build, the associated job, repository and links to download build artifacts. When creating or editing a job just specify the url of your service under Notifications.