Random thoughts on being a CI engineer

2019, Jun 30

In this post, I am going to talk about my experiences when working with CI/CD for iOS applications and some valuable lessons I learned.

1 In the past few months, I have been intensively working on CI/CD features in my team. My teammates sometimes refer to me as “the CI guy”. Before me, “the CI guy” was someone else who is humble, and quiet. After he left the company, I became the main PIC for CI/CD-related issues.

2 When working with CI/CD, most of the time, I code scripting languages (Bash/Shell, Ruby, Python…), not Swift. The scripting codebase (only accounting code written by our team) in my project consists of:

That means I can explore more technical areas of interests. At least, I can read .py, .rb and .sh files with more ease than before. I am now less reluctant to debug a 3rd party tool (such as Fastlane, CocoaPods, etc.).

There were a few times I debugged through a bunch of code to fix an issue and finally realized that I used Python syntax in Ruby code 😂. But it was fun.

3 Since CI/CD affects all developers contributing to the project, I felt like my work was a factor in team productivity.

Lucky me that my project has a large codebase. Engineers from many tech families contribute to the project on a regular basis. The amount of product features code added has been increasing. The same pattern happens to the number of tests (both unit tests and UI tests). Problems arise in terms of build & test time and test stability (mainly UI test stability) as a result… CI/CD work for the project is no longer as simple as setting up jobs to build and test the project successfully.

4 Being one of the few in the team to work with scripting languages, I felt a little bit isolated.

While my peers were working on some fancy product features, I was writing a basic python snippet to parse specific files. After a while, I realized that I started to lose my interests in iOS. When my teammates submitted a merge request, I barely mind reviewing his/her change.

Also, when I submitted a merge request (for a tooling/scripting work), I noticed that very few people reviewed my work. I guessed it was partly because engineers in my team had different levels of interests in scripting work and different levels of scripting skills.

Apart from that, I sometimes miss some logic in scripting languages because they are not my primary languages, and such code is not covered by tests. Sometimes, I had 1-2 more follow-up fixes after I merged a change. That pattern happened more frequently making me keep questioning my quality of work.

Although I gradually managed to overcome that negative feeling, there are a few times I still needed to escalate to my manager to get proper attention to my work :).

5 Sometimes, I felt like the misery of one’s lifetime is on me when I tried to debug an issue. For example, I didn’t get proper code coverage data, who should I blame: Xcode, or CocoaPods, or a misconfiguration in the project. While investigating the issue, I found something abnormal (which could possibly be the cause). When I looked into that unusual behavior, I found another one 😟. Eventually, I ended up with tons of questions that need to be answered 😵.

My rule of thumb: before you investigate something, come up with some hypotheses first. Verify one by one. Before verifying any, bear that in mind (it’s good to write it down).

Above are some of my random thoughts on CI/CD work. I never call myself “the CI guy” because I only touch the tip of the iceberg as of now. I always feel like I lack a leap of thinking to become more experienced in this area. But anyway, some of you were/are/will be probably struggling like me. If so, do not hesitate to share your experiences.

tech
ci