Hero image for Deployment


To deploy a web application to the hosting server or mobile application to users, we follow a Continuous Delivery (CD) practice. The main principles are:

  • The application can be deployed at any time
  • The application can be deployed with the push of a button and/or more commonly by merging a pull request
  • No human is involved in the whole deployment annihilating the possibilities of most common process errors



We use Semaphore to deploy (and test) the web applications that we build.

From the beginning of a project, both the staging and the production servers must be setup, and everything must be configured so that Semaphore can deploy the software to both servers.


We use a self-hosted Jenkins CI server to deploy (and test) the mobile applications that we build.

For both iOS and Android, we also use Fastlane in the Jenkins pipelines to simplify and improve tedious build processes such as management of certificates and provisioning profiles.

👉 Read more about our Jenkins setup in this guide.

Release Manager

Release management entails planning, scheduling, and controlling a software build through different stages and environments.

By default, the Team Lead is the Release Manager. But this role is encouraged to be delegated to other developers in the squad. By sharing the mantle of Release Manager the following can be achieved:

  • Team members will be aware of the release checklist, and how to run a complete release cycle through it.
  • With multiple developers taking turns doing releases, we end up with a more robust process as each developer brings their share of optimizations.
  • It encourages the Team Lead to learn how to delegate work effectively.

The Release Manager role has the responsibility of owning the deployment process by executing deployments on behalf of their development team and playing a role in automating/ optimizing the deployment process.

Every developer should clearly understand the steps required in a release to carry out the responsibilities of this role. It is the responsibility of the Team Lead to plan and delegate this role to a member of his/her team. This should ideally take place during the sprint planning that precedes the end of one rotation.


  • Fully understand the details of the release process; this includes what could potentially go wrong, and how to fix those issues.
  • Understand and plan for the release timeline and lifecycle, including understanding test cycles ran against a release and when to expect those results. Traditionally, a beta release is required at the end of every sprint.
  • Sometimes, a release date might be difficult to honour due to unforeseen problems. Communicate with stakeholders (clients, testers, fellow developers, project managers, etc.) about any changes, issues, updates, etc. related to the release schedule and process.
  • The Release Manager needs to be well aware of the changes going into a specific release version, and, if necessary, voice concerns to the Product Manager when it seems that the release will not be on time, or deliver less than the expected changes.
  • Conduct all official communication with stakeholders concerning the release in a timely and clear fashion, such as sending an email to notify stakeholders once the release has been completed.
  • Carry out the release process to completion by following a release checklist. If there isn’t a release checklist in place, each Release Manager should iteratively contribute to such a checklist until it reaches a complete and stable state.