This is the third part of our series “Beginner Guide to Android Build system”. We started with what build is and how Gradle plays its role in Android. Part 1 covers a lot of basics about Build files, dependency, Build script and sections of Gradle. If you have not read, I recommend doing so. Part 2 is more Android oriented and how Android uses Gradle build files. How a multi-module project is very easy to manage with Gradle and so on. Read Part-1 here and Part-2 here.
This article is for beginners, if you are already familiar with CI/CD and convinced with the need of it. You can continue binge-watching Netflix.
Summary of Part1 and Part2: We know the code is converted to another form (artifact) so users can use it. There are multiple ways to convert raw code into binary or executable. Gradle is one of them. It makes your life easy by managing dependencies, executing build tasks and generating the final output. Android uses Gradle for managing modules and build apk.
Everything is fine till now, what do we need more and why? What the heck is CI/CD doing? I totally get if you are scared of it OR you do not understand what is this DevOps thingy and how does it play role in our career? Why most of the employers consider it a plus to know about CI/CD? Why should a developer know about it? This article aims to answer these questions in a very simple way. You should be able to feel more confident about CI/CD hereafter and you can read in-depth somewhere else if it excites you. This will be an intro to CI/CD and Jenkins. These words won’t be foreign to you anymore.
CI/CD
Let me ask you a question. You are working on a project and you need to submit apk to Google play store OR any other distribution channel. How do you do it?
If you are one man army, you goto Android studio and build a signed apk. Maybe you are a bit pro and choosy in your coffee, so you go to command line and run Gradle. Remember our part 1 and part 2.
What if you are working in a team? Who builds the apk and from which machine? Yea, you could take turns. Who says it does not work? It works. But have you ever encountered a situation “It works on my machine”? (If you have not, you are not old enough in software ) Maybe your colleague complained you guys forgot his commit. Maybe someone was in a hurry and he did not run tests trusting all developers which 99.9999 times is a bad choice. But we are developers, we are united, we still do it. There are plenty of other things could go wrong here and we want to avoid them.
If someone you trust, advises you to take a road and save 10 miles, you do it. Why think here?
Similarly, why use old-fashioned risky way of building when there is a better solution? We are developers, we believe in automation. We want some technique to do this building process automatically for us. That my friend is CI/CD. A better solution. An automated way of building continuously and saving time for developers to taste that awesome Belgian beer. Let's see a formal definition.
Actually, CI/CD is made up of two words. CI and CD. Continuous Integration and Continuous Deployment/Delivery.
CI
Continuous Integration (CI) is a development practice where developers integrate code into a shared repository frequently, preferably several times a day. Each integration can then be verified by an automated build and automated tests.
CD
Continuous deployment is a strategy for software releases where in any code commit that passes the automated testing phase is automatically released into the production environment, making changes that are visible to the software’s users.
I believe CD does not make much sense in the mobile app world. However, partially you could deploy your app to some place like alpha channel OR to internal stakeholders. That's just my opinion which is a moo point.
I am a slow learner, so I will summarise before we proceed. We know we have to build code to some executable and Gradle helps us doing same. But we need other developers code, we have to run tests, we have to ensure other business requirements like translations and so on. This whole process can easily be delegated to a machine and someone clever did it. They made a nice piece of Software to do all these operational, boring and repetitive tasks of fetching code, running tests, emailing stakeholders and plenty of other stuff. That’s what CI/CD software like Jenkins does.
Glossary
I assume you won't be blank when next time someone is talking CI/CD. Let's visit a few words and technical terms we use in this context and then we will see more of Jenkins.
Job/Project
In simple terms, a command to execute other commands. It is like running an ‘sh/bat’ file but instead of opening terminal yourself, you create a button and on the press, it executes the sh /bat file for you. A Job in this context means to execute several commands so we can have a meaningful result (which is a binary in our case).
You can also think it as a pipe which has inlet and outlet. Inlet is the code and outlet is the binary. Few examples are Building and compiling the code is one Job, running Unit Test is another Job. Deploying the binary to some server is another Job etc.
Pipeline
Let’s say you want one Job2 to start when Job1 finishes. You want Job3 to start when Job2 finishes and so on. The sequential Jobs are called Pipeline.
The beauty here is if one Job fails the whole pipeline fails and stakeholders can be notified even when they are sipping their favorite beer. All of this is automated with a bare minimum human intervention.
I hope you understand now what CI/CD is and how it helps. Can we stop here?
More More and More…
In computer science, we started from bits and do you see where have we reached? Jenkins is not an exception. It has matured a lot. Maybe they started from the idea of just automating the sequential tasks. But now it does more than that and all of the features are making your life easy. A couple of features:
- You can schedule a build (Not impressed?)
- You can make the build trigger when someone commits to your repo (Impressed?)
- You can extend the second point and configure it more with parameters
- You can trigger a build with email/slack and other means
- If the build fails, Jenkins can send a notification to the person who might have broken it
- Share artifacts with others (No confusion)
- You can deploy when you want (Xmas sale at sharp 12:00 AM)
- The plugin architecture makes Jenkins a lot more powerful
- and many more….
If you are a beginner, Hope You learned at least one thing new OR I made it a little easy for you. If you are still not convinced by the need of CI/CD in your project, call me for a coffee. I will try my best to convince you.
Tip
Jenkins is not limited to building your software, you can configure it to start your toaster as soon you get an email with the subject “Toast morning”. After all, it is a tool to run other commands. It is a dumb-smart software :)
Happy learning.
Writing takes time, Usually 1 day to write an article which offers months of learning. 👏 clap 👏 & share if you like it and follow me(Twitter) for the updates. Share, Comment or start a discussion. Feel free to correct mistakes.
