In the name of God
Hello guys, here we are again with another episode on the AIO series.
Before we start, let’s see what is AIO? AIO is the new side-project that I have been working on for a while now. AIO allows me to practice coding, implement new ideas, play with new tools, and a lot more. In this series of blogs, I’m going to cover pretty much all of the challenges, gotchas, recently learned stuff, and almost anything interesting to me during the development of this project.
In this episode, I’m going to walk you through (pretty much) all the steps that I took to setup a CI Server for AIO.
Someone would already ask that why do we even need a CI? it’s not a huge project or even a real business focused APP!
In my opinion, I can answer this question with two reasons:
- There is a ton of work we do every day repeatedly. They are mostly the same and identical to the one we did just a minute ago or yesterday or even on the last commit. most of them become so routine that sometimes we forget how many times we have to repeat them every day or how much time we actually spent on them or in better words waste every day. As an Android developer, I build my project every a few minutes, I try to run Tests on every APK generation, I want to quickly share my new released APK on Telegram/Slack. these are just a few examples and there are many many more.
- Enthusiasm and hype! yeah, that’s an honest answer. everybody talks about CI/CD everybody says it’s so cool. helps in the long run. So I want to try it too!. if it helps I’m going to use it more and if it fails and does not bring the value everyone is saying we can easily abandon it with almost no cost! after all, I’m trying it on a side-project not a real-world app with millions of users.
So these two were enough for me to get me started on a journey to a CI backed project.
alright, where do you think we should start? I always start with what’s available for free and good support!
let’s do this! after a quick search I found these options:
To be honest here again. I did not compare my options very thoroughly rather picked one up based on how free it is actually and how user-friendly the setup and UI is. at the time of writing, Travis is a good option but it seems that I need to work way too much with YML files. I guess Jenkins needs a self-hosted server or something like that to get it started. Gitlab pipelines work best with Gitlab repos. CircleCI was very interesting but when I google I found more results for others than CircleCI. so the only option I’ve got here is Bitrise on the plus side Bitrise is OpenSourced (like AIO!). So I made the call! Bitrise it is then!
I really like the onboarding/setup process and how quickly it was to get started. UserInterface is awesome and almost everything is done by drag and drop. on top of all that most of the work they do is OpenSourced and they are open to contributions.
It’s very easy to get started with Bitrise you just have to create an account or simply use one of the OAuth options. Since AIO is on Github I used Github sign in. From there it was only a few clicks to get the project running and building it for the first time on CI. As easy as that. the default Workflow covers pretty much everything you need but adding/removing work on every run is done by opening Workflow Editor and simply drag and drop the steps you need to/from the workflow.
I’m going to cover the basic usage of Bitrise steps here to help you guys skip the understanding of these steps.
If you open your Workflow editor you will see your Workflows and all the steps in each workflow.
on the top tabs, you can configure/fine-tune your Workflows even further.
in this tab, you can fill in your signing keys and upload your Keystore or any other file you may need during the build process (like google-services.json). don’t worry they will be stored in secret variables and no one will be able to see them except yourself or anyone on your team who has the permission to.
you can put any variable that is sensitive to you or your project and again keeps them safe (using Encryption mechanisms) from the eyes of other people. remember if you allow them to be visible for PR you actually put your Secrets at risk and someone could be able to reveal them.
this step is pretty similar to the Secrets but only they are not secret and they are for normal and not-sensitive data. and by default, they are visible to PRs. be careful which you choose for your variables
using this step will help you to easily manage which workflow should run on every event that has been fired from Github. in this tab, you may select branches and Push/PR event for the workflow. for example, I have assigned a Deploy Workflow to the master branch and a not sensitive check Workflow to PRs.
It allows you to change the machine OS, Project Framework and a lot more fundamentals for your projects or even a specific Workflow.
Last but not least is Bitrise.yml. this tab will print out the yml file you are using for your project. this file is been generated for you when you make any changes to your Workflows or changing other elements on your project. if you are like me and want to learn more about .yml files I suggest you have a look at this file. it’s a lot of fun. you can even run this yml file using Bitrise CLI locally.
To wrap up I like to point out a few small things that I found on Bitrise which might come in handy for you guys too:
If you upload a file on Bitrise to use it on builds, you have to add a Downloader Step in your Workflow to download it on the machine before you can use it.
Your Secrets are all safe as I have mentioned earlier and one of the aspects of keeping them safe is to keep them away from PRs. but if you decide that you really want to use a Secret during PR build you can do so by enabling “expose for Pull Requests”
Bitrise Workflow Steps are pretty massive and the team has created almost anything you might need in advance. Make sure to have a quick look at all the Steps before doing anything.
Just in case you don’t find the step you need, you may use the Script Step to create what you need with the power of scripting. with this Step, you can achieve almost anything. also, make sure you don’t reveal anything sensitive unexpectedly.
There are a few Add-ons (currently Testing and Rolling Builds) on top of Steps. They come in very handy especially if you want to publish the result with others.
I have created my first CI machine for AIO. and the more I go forward I can say it’s more handy and useful. all and all in one sentence: CI Server is a huge time saver.
Interested in AIO? make sure to have a look and even contribute on Github:
AIO on Github
You can always get the latest version from AIO Telegram Channel.
It’s been a long post. Thank you for staying with me during this process. Hope it helps