The Social App: Repository Setup
If you don’t know about this project’s motivation, read the first post here.
When setting up a project, the first step is to decide where to host your code. This is an important decision, as it will impact all our code review flow, pull requests, tools integrated into it, and so.
If our project is going to be private, my personal preference is Gitlab, but generally, Bitbucket offers broader options for integrations (like CI servers). As this project will be open source, the no-brainer option is undoubtedly Github.
So, the repository URL is https://github.com/rafaeltoledo/social-app.
To create the project, I used the Android Studio wizard (currently, at version 3.1.0), and used an empty project template. I didn’t configure an initial Activity, neither selected the Kotlin support, as I want to set up the project and build files by myself, so we can better understand what’s happening, and will keep it more organized than the generated script.
At this point, it’s important to note that I’m not using any Canary version, as this is a project that will hit production. When developing professionally, it’s important to think about this. On my development computers (both at work and home), I always keep the latest stable version of Android Studio, and the newest canary builds, so I can experiment, check new features, and so.
So, with the project created, I pushed it to Github.
The last step related to the repository is to configure the persistent branches. They will not accept commits directly, and our (future) CI server will watch them. In addition to the branch master, we will create a branch called develop. Initially, I just derived this branch from the master and uploaded it to the repository.
The idea here is that the code in the master branch mirrors the code of the application currently in production (Google Play) and the branch develop, what is currently with the stakeholders and alpha testers of the project. For our app, the idea for those builds is to be available on the Google Play Alpha channel for a closed group of testers.
Let’s also configure these branches on Github, such as requiring the approval of Pull Requests (PRs), requiring PRs to be synchronized and passing the checks (we will soon integrate linters, tests, and so on)
Let’s save those settings, and that’s it!
In the next post, we will configure the CI server to build this initial project, and plug it into Github’s Pull Request checks.
See you there! 😄
