You should use CI/CD for mobile apps

You should use CI/CD for mobile apps

In this video, I’m going to discuss continuous integration for mobile apps. I’ll be mainly focusing on iOS and iPadOS app development, but this should apply to android as well.

Topics I’ll cover:

  • What is continuous integration
  • What is continuous deployment
  • Why you should use CI/CD
  • How to configure

Grab your coffee or drink of choice and I’ll get started!

What is continuous integration

Continuous integration is a software development practice where members of a team integrate their work frequently, at least once a day. Each integration is verified with an automatic build and automatic tests, though tests aren’t required.

Do you have to be on a team to use continuous integration? NO. You can use CI tools with however many people are working on the project which could be 1 or 10 or 50. 50 might be too many, but I’m sure it happens somewhere.

You might also be thrown off by the word integrate. If you’re working in Git, then think about pushing to a remote branch and then merging to the main branch.

What is continuous deployment

It’s the part that comes after continuous integration and basically means that the main source of truth will be deployed automagically without manual intervention.

No more guesses if the source of truth or production will go down.

It will just happen like magic.

It can happen like magic because there should be a lot of testing and they should be good tests so that production doesn’t go up in flames and your app is dead in the water…

Why you should use CI/CD

You might be wondering why you should do this and why it’s important if you are a solo developer.

Well here is why you should be doing this:

  • Quick to get bug fixes out - if you’re running tests every time you push to the cloud, then you know when or if your app will fail. If you’re tests pass, then you can get that bug fix out quickly without worrying that you’ve broken the entire app
  • Smaller code changes go out to user - usually smaller code changes means less unintended consequences
  • Testability improves and increases since smaller changes are going out. You don’t have to test a broad set of features or bugs. You’ll get to target very specific items
  • Less human errors. The more you automate the little things like increasing build numbers and pushing to the app store for deployment, the less likely you are to mess it up.