Continuous Integration/Delivery, are they necessary?

Automation has been one of the core processes which most enterprise companies wants to adopt nowadays to manage the quality of deliverables. Incrementally, such process will converge with DevOps to manage pipelines of jobs generated by multiple projects. In short we call this entire package CICD. A code commit automatically generates a testable build with the new code changes. It’s like adding sprinkles on your yogurt and you get to taste it immediately.
What exactly is Continuous Integration (CI)?

It is a simple automation procedure where a single pull request made to a targetted branch will trigger a job to perform:
- Compilation
- Build
- Unit Testing
- UI Testing (optional)
Once this entire procedure runs successfully, a message can be sent back to your pull request to update the status.
Here, there are many possibilities of how this procedure may fail:
- Machine running the job went offline
- Compilation failure due to missing files, versioning or catastrophic issues like framework no longer supported
- Test failures due to broken implementations
- Other unexpected issues
Jobs failure can be frustrating, although it saves us a huge amount of time, when it fails, it may take us a fair amount of time to fix.
Now that you have a basic understanding of Continuous Integration, let’s take a look what’s Continuous Delivery.
What exactly is Continuous Delivery (CD)?

It is the next automation procedure that follows CI, which in most normal circumstances, is when the pull request is merged to a develop branch, then from the develop branch, a job will be triggered to update the main application.
Hold on, did you just say “develop” branch?
I’m glad you ask! A very standard Git Branching template that most companies follow is as such:
- Master Branch (copy of latest production code) -> merge with latest release branch
- Develop Branch (latest development code) -> Branch out from master
- Feature branches (i.e. login, view-profile, get-movies-data etc) -> merge to develop
- Release branches (i.e. release-1.0, release-2.1) -> Branch out from develop
- BugFix branches (i.e. fix-login-crash) -> merge to develop
Now with this Git branch template as an example, if a pull request is made for the fix-login-crash, CI will ensure that the code changes made to this branch passes the test, and once the pull request is merged into develop branch, a CD will trigger to generate a new test build.
Final Words
This is just a short write up of CI/CD ran by many projects nowadays, I have written a short tutorial of how to set it up on iOS project without the pull request flow here.
