Skip to main content
Version: Next

Mobile CI guideline

This section describes how to proceed with branching, PR and releasing for any features developed after go-live of Navida PRO.

Branching strategy​

For further development of Navida PRO, a trunk-based development approach has been selected for the branching strategy. For detailed description please check Google, for example this link.

Key assumptions:

  • developers should merge (relatively) small pieces of code with the target, long living branch - develop in case of Navida PRO
  • any update of the develop branch needs to happen via a PR process (see below for details)
  • any breaking change needs to be guarded by a feature-flag (see below for details)
  • bugfixes are non-breaking by nature and should be merged without feature-flagging in place. If not the case - handle individually
  • develop branch needs to be shippable at any moment
  • once a release A.B.C is to be published, "release/vA.B" branch shall be created and published. In ideal condition, when no hot-fixing is needed, this branch will remain inactive. See "Releasing strategy" for more details

Feature flagging​

Feature flagging system is essential in trunk based development to assure that code from the develop branch is shippable at any given time, even if some features are not completed or not meant for release. From the implementation perspective it's a simple system of providing a boolean value in a configurable manner.

Please note the rules for determining the final value:

  • L1 is based on resource value that is configurable across different App flavours (dev, sapm, prod) in a manner similar to eg. the backend url
  • L2 is based on value stored in shared preferences (user defaults) and is configurable in the runtime, via dedicated developer-options screen (to be developed)

Configuration via CMS (as L3) is meant for future consideration.

Please follow the rules listed below when working with feature-flags:

  • use as little feature flags as possible. By the rule of thumb, given feature shall use only one feature flag
  • feature flags are meant to be short living. Once given feature is released and tested in production, there should be an extra task created to remove the flag and the original code. This should be considered the main differentiator between feature flagging and configuration systems
  • if the original behavior of the App can be preserved via configuration and this constraint is considered the target state (eg. when developing an extra configuration for a single tenant), no feature flagging is needed
  • by the rule of thumb, feature flags should default to the state of current App in PROD (preserving the original behavior) for all environments. When agreed, the configured value should change to enable proper testing. For an individual need to enable the feature, developer menu can be utilized

PR process​

A proper PR process helps to maintain the best possible code quality. With help of Azure DevOps pipeline automatization, it's ensured that the code from a given PR branch needs to meet certain quality-gates, before it's allowed to be merged into develop branch. See below for the complete list of requirements:

  • PR must be built
  • PR must be unit tested
  • PR must be screenshot tested
  • PR must pass static code analysis
  • PR must meet SonarQube quality gate (test coverage, code smells, OWASP check)
  • PR must include latest commit of the target branch
  • PR must be approved by at least 2 engineers

Releasing strategy​

Thanks to the trunk based development approach, feature delivery and publication are decoupled, making the releasing strategy simple. Navida PRO targets a release cycle of - 1 week, for releases meant for internal testing. Once any of those is accepted as production, appropriate release shall be created. It's planned for this to happen in a 3 weeks cadence. Actual App release shall happen by Azure Devops pipelines. They shall be configured to run upon a publication of a specified tag to develop or release/vA.B branches. Tags shall be formatted as "release/environment/vA.B.C", where environment reflects one of the App flavors.

Azure DevOps pipeline shall be able to override the build number part in the App version string (so the "C" part above), to avoid the need to commit App version updates in the release/vA.B branch.

Summary​

Please check below for a picture of the development process sample.

What can be observed:

  • feature PLATT-124 is developed with multiple (2 in the picture) PRs. In both cases, same feature flag (feature-flag-A) is used
  • another feature (PLATT-123) needed a single PR so far. It's handled by another feature flag (feature-flag-B)
  • there was a release/v1.0 branch created. It serves for the whole v1.0.* family of releases
  • App version is bumped in the develop branch (using version/v1.1 branch) to a) prepare develop for next family of releases, b) make it visible for the developers what is the next version
  • TAG release/dev/v1.0.0 triggered a publication of the App to AppCenter, targeting DEV environment. During test phase, it turned out that a hotfix is needed. It's first developed in hotfix/PLAT-789 branch, reviewed and merged to release/v1.0 branch. Afterwards, the fix should be cherry-picked to develop branch
  • Another TAG release/dev/v1.0.1 is published, triggering an App publication. It's tested OK in DEV environment, so release/sapm/v1.0.1 is pushed, triggering a SAPM App publication