v1.0 🤖 — Automate with Continuous Integration

Introduction

Hello everyone! Thank you for signing up for Since Last Commit, a newsletter that aims to bridge the gap between mobile development and release engineering. Through this platform, I would love to share anything/everything related on how we can build better products, become better engineers and be owners of every line of code we write that gets shipped to our users. I am not an expert by any means, but I hope to use this opportunity to learn along with you. Let’s get started!

Cool Reads

Tip: Here I share my favourite quote of the week

“Ask a programmer to review ten lines of code, he’ll find ten issues. Ask him to do five hundred lines, and he’ll say it looks good” ~ Gene Kim, The DevOps Handbook

Continuous Integration

Building software is a huge task which involves a lot of people. Software needs to be built on time, has to be stable and abide to certain specifications. When developing software, the number of tasks also tends to increase. I came across an example recently that software development can be looked at as maintaining a garden, rather than constructing a building. It needs to be taken care of and groomed in various situations. During the lifecycle of a project, bugs are introduced, code smells are lurking and performance issues are haunting the development process. As more and more tasks are required to groom the project, Continuous Integration (CI) can help automate those processes earlier in the development cycle.

CI is a practice of merging code from multiple contributors into the mainline continuously and automatically. Prior to merging, the CI must ensure that the code works as it should, passes the quality standards and does not break any existing features. Any issues with the CI pipeline will prompt the developers to quickly make the required changes even before merging to the mainline.

Customized to the project’s needs, the pipeline usually contains the following three stages: build, lint and test for any project.

Build

Any new code must be able to build and produce some sort of an executable. For an Android project, this is the APK. The coverage of this stage is to ensure that there are no syntax errors, dependencies issues or any other problems that may become an obstacle in obtaining the application.

Lint

Once the application can produce a build artifact, it’s important to perform a lint analysis on the source code. Linting is a process of finding issues that could turn into bugs or pieces of code that do not follow best practices. Usually, these are pre-defined to certain languages like the Android lint that comes as a pre-defined Gradle task. Lint rules can be customized to follow any structure. For example, organizations can use lint rules to structure their projects and enforce how teams should name their classes or variables.

Test

Even though we are able to build an artifact and perform analysis on the codebase, that may not be enough to validate whether the application works or not. Testing is important process to ensure that the application behaves as it should during runtime. This include unit tests that validate the core logic as well as UI tests that interact with a device. Tests should grow with the project, so every line of code is validated in one way or another.

Tips and Tricks

• It’s all about feedback: ensure the pipeline is fast and structured in stages, so it can report any issues at the earliest.
• The pipeline works for you: don’t it let be a bottleneck, instead use it to your advantage and automate tasks you wouldn’t want to do manually.

Conclusion

That wraps up our first newsletter. Hope you enjoyed it! If you have any questions, feedback or concerns, feel free to reach out to me on twitter (@asadmansr).

Keep hacking on!