Kristal Blog

>

Tech Blogs

>

How Kristal.AI built the iOS app CI/CD pipeline and saved up to 2 hours of developersโ€™ time daily

How Kristal.AI built the iOS app CI/CD pipeline and saved up to 2 hours of developersโ€™ time daily

Kristal.AI is a digital wealth platform that aims to provide private banking solutions through transparent access to investment and services, which are traditionally reserved for the Ultra-high net worth. We leverage technology, algorithms, and human expertise to help clients with portfolio allocations and optimization. We are licensed and operational in Singapore, Hong Kong, and India.At the center of Kristal.AI, sits the 35 person engineering team. While small in number, for building and managing our digital wealth management platform. We are the tech-savvy ones and love to try different things to improve the performance, scalability, and reliability of the platform.Amongst other things, the team is driven by this simple motto:"Some things are meant to be done by machines."-โ€ŠVineeth Narasimhan, Co-Founder & CTO, Kristal.AI.Hereโ€™s the journey of how we built our iOS app CI/CD pipeline using Github Actions.

The Problem Statement

Before we discovered the magic of GitHub Actions, we used to manually attach the QA iOS device and give the build via Xcode. This made sense to our use case at that time since it saved time, rather than going through the DevOps route.Then with the pandemic and WFH situation, we were forced to rethink this approach as we could no longer give the build manually.We tried a number of things. While all of them worked fine in the short term, none of them emerged as a viable permanent solution.Below is a non-exhaustive list of everything we tried and why it failed.Our non-tech readers can gladly skip to the next section, where we talk about what actually worked and how it benefited us.1. We started giving builds via TestFlight. Why it failed: It took a lot of time for a build to upload and be available to QA, thereby eating up time even for small changes.2. We then tried out giving Ad hoc builds for our internal testing which saved us some time. Why it failed: The developer had to manually upload the .ipa file to our S3 bucket via Jenkins which was taking up the developerโ€™s time.3. Then we moved to Fastlane deployments. This really saved the manual upload of the build to S3 time every time. Why it failed: It was still going via the developerโ€™s system. It would take around 40 minutes for Fastlane to Build and Upload to S3 automatically. That meant the developer was blocked off work during these 40 minutes. We gave 2โ€“3 builds daily, which meant about 2 hours of our developerโ€™s dev time daily. Also, our app build was now fully dependant on that developerโ€™s system. What if the developer is on leave or his/her system crashes?4. We then thought of installing a Mac Mini in our office premises and install this Fastlane workflow on that machine and use Jenkins to trigger builds. Why it failed: It was difficult to monitor the Mac Mini remotely and the internet might not always be stable 24/7. It would also be very difficult to debug the Mac Mini system remotely in case of any issues in the setup.5. AWS recently launched their macOS machines in cloud Why it failed: They were too costly to be used for the build and would not have justified our budget.After trying out multiple solutions, we finally decided on Github Actions. It was a much more integrated solution and best suited for our use case. It was also the solution that best suited our budget. Now all our staging and prod builds automatically go via Github Actions.In a later section, we get into the details of how we implemented this development. But first let's take a look at how this benefited the platform, the team, and the business overall:

  1. It freed up the developerโ€™s time that was getting wasted due to the system's dependency. We ended up saving around 1.5โ€“2 hrs of our developer time daily
  2. Now our developers can focus on building great apps rather than worrying about giving out builds
  3. Saving developersโ€™ time eventually saves business cost
  4. We eliminated the dependency on a single developer machine
  5. We were also able to give out builds much faster as the Github ecosystem is very robust and the chances of failure are fewer

The Implementation

Now to the tech-y part of the article. The Implementation. Hereโ€™s how the team implemented this development, broken down into 3 Jobs:

In a Nutshell :

Workflow Steps Overview :

Workflow In-DepthSummary: This workflow is aimed at providing IOS build for testing on a daily purpose. The jobs are run synchronously.No of jobs in the workflow : 3No of machines used: 2 (macOS and Ubuntu)Job 1 Steps (Build) :

  1. Send message in Slack that Build has started
  2. git clone from the staging branch in the freshly booted macOS machine
  3. Check if the correct Xcode version is used
  4. Configure keychain. Distribution certificates need to be in the OS keychain for Code Signing. So as we get a fresh machine always, we need to create a new keychain and upload certificates there
  5. Certificates and profiles are in git in encrypted form. So they need to be decrypted form to be able to upload to the keychain. So we decrypt the certificates and profiles in this step
  6. After decrypting the certificates, upload them to the newly created keychain in Step 4
  7. Xcode needs to find profiles in a certain path. So profiles are uploaded to this path. These profiles are basically provisioning profiles that tell the Xcode what certificates to use for Code Signing and which devices are whitelisted for the app to be installed.
  8. Install NodeJS so that the npm command can be used
  9. Install NPM packages. Make sure to have a package-lock.json for correct NPM packages to be installed
  10. Install Pods. These are IOS Libraries. Make sure to have a Podfile.lock file to install the correct library version.
  11. Build and archive the app. The app is converted into binary format
  12. Export the archive file into IPA files which can be distributed to users for testing.
  13. Send message in Slack that Build has completed
  14. Upload app files in storage so that they can be retrieved later across jobs.

Job 2 Steps (Uploading to S3) :

  1. Send message in Slack that Build is uploading to S3
  2. Download the app files from the shared storage from Job 1
  3. Configure AWS credentials
  4. Copy app files from ubuntu machine to S3
  5. Send message in Slack that Build is ready for testing

Job 3 Steps (Uploading to BrowserStack) :

  1. Upload app files from the Ubuntu machine to BrowserStack so that whenever Automation tests are run, the BrowserStack always has the latest app
  2. Perform Unit and UI testing of the whole app
  3. Prepare Testing Report and publish it in Slack

Job 4 Steps (Uploading to TestFlight) :

  1. Upload the app build to TestFlight if is a Prod Workflow

Conclusion

CI/CD is a must in todayโ€™s world which really enhances your tech stack. It really saves a lot of boring, repetitive tasks that can be easily done by machines and also is very cost-effective.

By

Dhruv Jindal

July 7, 2021

Liked it?
Share it with your friends & colleagues!

Related articles

Go to Blog

Ready to start investing?

A fully digital onboarding process that can be completed within 15 minutes.
No more voluminous paperwork and queuing!

How would you want to invest?

Your Details

Financial Guide Details

Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.

Your Details

Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.

I understand the financial products and would want to proceed with investing without a financial guide

X