Continuous Delivery
Principles
To deploy a web application to the hosting server or mobile application to users, the team follows 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 the most common process errors.
Tools
As a general rule, when a client already uses a specific CI/CD tool, the team usually recommends to use the same tool for all applications to limit the number of different tools used. For instance, when a client already uses Jenkins CI for their CI/CD needs, the same tool should be used for the new applications that the team builds.
Web
GitHub Actions is the preferred tool to deploy (and test) the Web applications that the team builds.
When a client does not use GitHub to host their repositories, the team usually relies on the built-in CI/CD solution of their Git provider. For instance, Bitbucket provides Pipelines and GitLab provides its own solution.
From the beginning of a project, both the staging and the production servers must be set up, and everything must be configured so that the application can be deployed via the CI/CD solution to both servers.
Mobile
The following tools are used to deploy (and test) mobile applications that the team builds (ranked in order of preference):
For CI/CD purposes, mobile applications have more stringent hardware requirements (e.g., CPU, RAM, disk storage, etc.). Therefore, the selected tool depends on the type of applications developed and the budget allocated for CI/CD.
For both iOS and Android, the team uses Fastlane in the CI/CD pipelines to simplify and improve tedious build processes such as management of certificates and provisioning profiles.
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, the team ends 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.
Responsibilities
- 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.