Android Development Github workflow - sumanksp/reference GitHub Wiki

Welcome to the Android-Dev-Team wiki!

Branching Model

The branching model is composed of 5 main branches type:

  1. master
  2. release-X.Y.Z
  3. dev-XYZ
  4. hotfix-XYZ

Protected branches

master

The main branch, only code validated by QA should be merged on master. The release tag must be set on this branch. Jenkins build uses this branch to build official releases.

release-X.Y.Z

This branch is used during one or more sprint to merge developments for a specific target version. Once every developement have been commited, a PR is raised to merge into release for Jenkins build to run and create a RC for QA. This branch should be kept forever. The RC tag must be created on this branch. Jenkins build uses this branch to build release candidates for QA.

Non protected branches

dev-XYZ

This branch is created each time a new issue has been created in github. This branch should only be used to implement the content of the issue. Once the development is ended, a PR is raised from dev-XYZ to release-X.Y.Z. After succesful merge, this branch must be deleted.

hotfix-something

This branch is created when a fix is implemented while no issue has been created in github. This should happen rarely. Once the development is over, a PR is raised from hotfix-something to release-X.Y.Z. After succesful merge, this branch must be deleted.

Logger

Logger is a logging library by Organization which uses Timber under the hood.

Setup

To start with there is no setup required except adding the CIDLogger module/library in your project path.

CIDLogger has two variants DEBUG and RELEASE

  • DEBUG : Uses Timber.DebugTree() and will be automatically picked by Gradle when the app is in DEBUG mode.
  • RELEASE : Release build extends Timber.Tree() which is custom tree and will be used to log Errors and Warnings and will use android.util.Log for logging. Debug logs will not be shown in release builds.

Release variant can be used in future to log crashes and error to Crashlytics or any error reporting service.

Usage

How to log debug logs?

debugLog("This is a debug log")

How to log error?

errorLog(throwable = exception , message = "This is an error message")

How to log warnings?

warnLog(message = "This is a warning log")

Extra feature

If you want to distinguish your application logs, you can add a postfix string to the tag using below method. Make sure the below method is called in Application class at the earliest.

Logger.setApplicationPostTag("MyApplicationName")

And this will add your provided string to each TAG in logcat as below

2022-11-18 10:33:24.938 1708-1708/? W/Feature_MyApplicationName: Attempted to add notif for locked/gone/disabled user 0

Code Commit Checks

Code commit tools used

  • Spotless
  • ktfmt
  • LeakCanary

Steps to perform before commit

  1. Check for leaks using running debug builds on device

  2. Run spotless check (Automated using Githooks and runs before every commit)

./gradlew spotlessCheck
  1. Apply automatic fix using spotless (Manual Run Required)
./gradlew spotlessApply

Code review rules

  1. For each PR, code reviews are mandatory.
  2. For each PR, it must be advertised on a common Slack or Skype channel with all Android developers.
  3. In best case, code review should be performed in 2 hours, and not more that a working day.
  4. Kindness in code review is not an option.
  5. Keep an open mind, and keep in mind that code reviews help reviewers and reviewed developers to step up!

Conventions

Coding

In order to ensure a common code formatting through all Android projects.

Tools

Two plugins must be installed on Android Studio: google-java-format (for Java) and ktfmt (for Kotlin). These are 2 plugins based on spotless.

Installation

In Android Studio, go to File -> Settings -> Plugins in the search bar, search for google-java-format and install the plugin. Install also ktfmt plugin.

Usage

For google-java-format, go to File -> Settings -> Other Settings then select google-java-format Settings and check Enable google-java-format For ktfmt, go to File -> Settings -> Editor then select ktfmt Settings and check Enable ktfmt

Each time you will press CTL+ALT+L the source code will be formatted using the 2 plugins depending the type of language.

Commit messages

Convention

For a better traceability and easier automatic release note generation, a convention has been defined for commit messages:

  1. A commit message must start with a tag among [FEATURE], [BUGFIX], [BUILD], [MAJOR] and [MINOR] (This list can be completed).
  2. Only [FEATURE] and [BUGFIX] commit messages will be kept for release note

Tags

  • [FEATURE]: A new feature added to the app / lib. If at least one [FEATURE] commit is present, the second digit of the version of the app/lib must be incremented.
  • [BUGFIX]: A bug fix. If there are no [FEATURE] commits, only third digit of the version of the app/lib must be incremented.
  • [MAJOR]: A major update in the software, with big impact, but with no interest fior the customer (for example project structure update, new dependecy used instead of another...)
  • [MINOR]: A commit that has such a minor impact that it should not be specified in the release note (for example gitignore update, version incrementation...)
  • [BUILD]: A commit related to the build system for example dependencies update, gradle task added...)

Commit message hook

A commit message hook is provided to ensure that this convention is repected. It must be create in .git/hooks folder of the project as commit_msg with following content:

commit_msg=$(cat "${1}")

case $commit_msg in
  "[FEATURE] "*) exit 0 ;;
  "[BUGFIX] "*) exit 0 ;;
  "[BUILD] "*) exit 0 ;;
  "[MAJOR] "*) exit 0 ;;
  "[MINOR] "*) exit 0 ;;
  *) {
		echo >&2 Commit message must start with [FEATURE], [BUILD], [BUGFIX], [MAJOR] or [MINOR]
		exit 1
	}  ;;
esac

Fixing bug implementing new features

  1. Remove every unsued imports
  2. Create test use cases for the fixed code. I don't want us to go through all the service and implement unit tests for every API, but every time we fix something, we should think about unit testing it, so that it will be covered for subsequent modifications.
  3. Maybe, once the PR has been approved by one or more viewer, and before the merge, we can format the file using CTL + ALT + L using javadoc or ktfmt (but beware of default settings for those 2 tools as it formats in 2 spaces indents by default). As we do it AFTER the PR has been approved, we won't be disturbed by a bunch of modifications that lead in very complex code review.
  4. As much as possible do not let warnings in the code, but this can be tricky and time consuming.
  5. Remove commented code as a rule. If it is commented, then it is unused

Some git useful commands

Git useful commands

Delete a branch

git branch -d BRANCH_NAME
git push origin :BRANCH_NAME

Explanation

The first command deletes the branch locally. The second deletes the branch on the remote repository.

Remove local reference to a remote branch that has been removed

git remote prune origin

Explanation

When someone removed a branch remotely on origin, this command deletes the reference (origin/branch_name) locally. Useful after a merge where the branch has been deleted after success.

Version name conventions

Naming versions: conventions

We use 3 digits to name version: X.Y.Z

First digit: Software Component Generation

First digit is used to name generation of the software component.

It should be incremented only in case of backward incompatibility for libraries, or major architectural changes for apps.

Second digit: New feature(s)

Second digit is incremented when one or more new features have been implemented.

Third digit: Minor changes/ bug fixes

Third digit is incremented in case of minor changes or bug fixes.