My second article in a series of React Native articles on how we use it here at Blazing Edge. The first article covered React Native essentials such as project structure, development tools, environment variables, tips, and more. In case you missed it, check it out.

At Blazing Edge we care deeply about the quality of the product and the transparency towards the client. This is exactly why one of the first things on the project is setting up Continuous Integration and Deployment. A happy client is the only client we want and in the world of native apps we want them to be able to download and test at any time.

I’ll be writing about how much Continuous Integration and Deployment has helped me with building React Native applications and delivering them to the client, making everyone happy and worry free by relying on automated services.

About Continuous Integration and Deployment

Developing applications is a fun process as long as you are creating them for yourself. The moment you start deploying your app to testers or production, or a new member joins the development team, things get serious and there really is no room for errors.

The whole idea behind Continuous Integration is to keep monitoring your code and perform tests on every change to ensure that the changes won’t break existing codebase.

While you can check your code manually before pushing commits, by linting your code, running tests, checking environment variables - this is something that should be done automatically and that’s why we need Continuous Integration.

Continuous Deployment is a process of building the application and delivering it automatically to users. It’s not as easy as deploying a web application, because updates for native applications have to go through the App and Google stores. There is a way to deliver the updates directly to users, but I’ll be writing about that in my next article.

Let’s go through benefits of using Continuous Integration and Deployment on a project, and later we will cover several companies that offer such services.

Everything is automatic

Once you set it up, you no longer need to waste your time on doing manual testing, building the app, delivering it to users, preparing app submissions, and deploying the app to stores. With the good configuration, continuous deployment can do it on its own. If you have a channel for notifications on Slack about the build process, everyone will know when to expect next version of the app.

Time is money

As mentioned above, everything is automatic. What does this mean to me as a developer?

Since I won’t have to lint the code, build application for each platform separately, and distribute the app to users/testers/client, I will be able to spend more time on the actual development and we’ll be able to deliver the product faster.

Worry less development

Before we had a continuous deployment service in our company, it took us around 15 minutes to prepare the code and deliver it to the client for testing. This was required on every iteration of the app, regardless if it was a public release, internal testing, or something else.

Now you just have one duty, developing the app and pushing the code. Everything else will be done by the CI/CD service. Best of all, everyone has access to these services, so the build and deployment of an application is not (and should not be) dependent on a single person.

Continuous Integration and Deployment as a service

While there are many Continuous Integration and/or Continuous Deployment services out there, they vary by price, available features, customizations, integrations with different services, technical support, community using it, etc. Here is the experience I had so far.

This was the first service we have used in the company, and it has saved us so much time. We were working on a project with two web application written in React.js, an Express.js API, and a mobile application in React Native for iOS and Android.

Creating releases for native apps was more difficult and time-consuming, since it required us to prepare the codebase and build the .apk and .ipa separately, and then send/upload the files once the build finishes.

When we found out about Mobile Center (that’s how Visual Studio App Center was called when we started using it), we gave it a chance since all other applications on the project had easy build/deployment, and let’s be honest, doing it manually is tedious.

What’s so great about the App Center?

It is easy to set it up, and at the time we were using it, it was in a beta so we got all functionalities for free - only difference now in the pricing is that you ‘only’ get 240 minutes of a build per month, so it was worth investing few hours to play with it and to decide that I won’t be creating builds and sending apps to the people manually.

Although this is an article on continuous integration and deployment, I do have to mention other services offered by the App Center, and that’s testing applications in Xamarin Test Cloud, distribution of apps via email to testers and app stores, crash reports, analytics, push notifications, and over the air updating. It has pretty much everything that a mobile application needs.

Even though everything sounds perfect, with a huge list of services which are free, in the end, we stopped using App Center to build our apps - why?

Well, it didn’t allow us to configure the build process. That was important to us because we were working on a complex application that had multiple environments in which application was supposed to be used and tested, such as development (used by us, the development agency), staging (another environment for developers to test, but it was supposed to be more stable than development so the clients would use it too to test new functionalities), and in the end, the production environment.

The only difference between these environments would be in several variables that would hold URLs or keys for our API, external APIs, third-party apps and such - all these values can be stored in environment variables which should be supplied to a building service.

Sadly, App Center did not have such functionality.

We had to keep all these values hardcoded in our codebase, and after every merge of code (development => staging, or staging => production) we had to manually change these values in the code. It may sounds like a simple job, but it’s was very nerve-racking due to fact that you could easily mess up application by connecting one of its parts to the wrong environment, and it was messing up our git history (we had to keep environment changes as a top/newest commit).

I talked with people behind App Center about this issue. They had plans to add such functionality to their service, but it just wasn’t in their short-term plans because they had to prepare for official release. However, after a few months, I received an invitation to try out the option to supply environment file in configuration. At that point, we have already switched to a different service which allowed us to configure the build process by supplying environment file.

Is it still in beta? Was it released to the public? No idea, you tell me. :)

Update: Got a reply from a user on reddit .

I supply config as environment variables in the AppCenter build, which has been supported for at least since I started using it last October. I use a prebuild script to echo specific environment variables into a .env file, which gets picked up by react-native-config. Works great.

I found out Nevercode while looking for alternatives that allow customizations. It was the first service I ran into and I was very impressed with the option to customize the build process, by uploading my own scripts, and (finally) being able to supply an environment file. I ran into some issues with setting up the project, and their support was really helpful.

I had a 14 free trial plan which had all functionalities available, but after looking at the pricing I realized that support for different environments on a project (they call it Workflow) comes at a price, it was available in plans that were starting from $200 a month. Because of that, we have decided to look for a service that has similar functionalities, but at a more reasonable price.

Keep in mind that I was looking into their service several months ago and it seems like they have changed their plans and pricing, now you can have support for workflows in $5.99 plan, good decision guys! Their pricing page.

While initially looking for services that offer Continuous Integration and Deployment, I have to admit that I wasn’t experienced enough to configure the build flow using Bitrise, so I easily gave up.

After some time has passed and my React Native knowledge has improved, I gave it another chance and I was finally able to understand and successfully configure the build on Bitrise.

Likewise Nevercode, it allows a user to configure the build flow by uploading our own scripts, supplying environment files. Where Bitrise excels are the integrations. There are 100s of integrations (also called steps) that you can add from marketplace to your build process. Best of all, they are completely free and open source. If you decide to contribute to Bitrise, for example, by creating a new step, they’ll give you a 50% discount on the team plan.

Regarding pricing, I do have to say that a Hobby (free) plan is okay if you want to see how things look like, what can be configured and how, and to build a basic project. Because of the 10 minute build time limit, you’ll definitely have to keep your Android and iOS builds separated, and there won’t be a lot of room for customizations. If you decide to purchase a Team plan for $50, you get everything unlimited, except the build concurrency which you pay $50 each, although it’s not like you are going to need it.

Conclusion

If you are someone who is just starting with React Native, and you just want something to build your app, Visual Studio App Center would be the best choice for you, and along with the build service, you get tons of other functionalities - keep in mind if you don’t choose (or need a service for building your app), you can still add crash reports, analytics, push notifications, over the air updates to your application.

If you have the time to play with customizations, and if you really do need customizations and full control over the build process, then I highly recommend Bitrise.

In the next article, I’m planning to write about building forms and user experience in React Native as well as how to instantly update your app by avoiding the app stores using over-the-air updates. Stay tuned!