Change Process in Cloud Platform
Cloud Platform team implements and encourage Infrastructure as a Code methodology to manage the platform. It means every single change is done through code (if you spot something different raise it with us please )
cloud-platform-infrastructure repository is our main repository where infrastructure gets created and all components fits together. From this repository everything gets linked
Mostly all components are terraform modules and they are managed in their own git repository, you can list all modules here .
Making Changes to cloud-plarform-infrastructure
- Create a PR which includes the change you want to make. Make sure the plan pipeline is happy with the change.
- Chase the team to get your PR approved, if it involves downtime ensure you have communications in place.
- Merge and wait until the apply pipeline applies your change.
Marking Changes to terraform modules
Updating a module is very simple and consist in the following steps:
- Create PR and ask a team member for approval.
- Merge PR
- Create a release following semantic version spec.
- In order to keep our definitions/instances up to date: update all existing instances in environments repo and cloud-platform-infrastructure repo. If this step affects team’s environments it will need planning and communication.
Step 2 and 3 can be done at any time and they don’t affect the running infrastructure because all terraform modules calls have pinned release version. None terraform module should point to master branches or latest releases automatically.
Finally create the PR which update the definition where your module is called and get ready to apply it following the guidelines above.
Making Changes to Helm Charts
- Bump chart version everytime you make a change
- Regenerate the
index.ymlfollowing this instructions
- PR against gh-pages branch
Making changes to environments (Service Teams)
Cloud Platform source of truth for team’s environments (kubernetes namespaces) is cloud-platform-environments, changes under this repository fol low similar process:
- Create PR and verify for the changes in the plan pipeline, if you are happy with them ask a team member fo r approval.
- Merge PR
Within environment repository we have end to end process fully automated with pipelines. Once the change is merged it is going to be automatically applied the apply pipeline (apply-live-1 and apply-namespace-changes-live-1) and if the change is destroying a namespace it will be done by destroy-deleeted-namespace pipeline
If changes involve downtime we must inform teams about it via slack (#cloud-platform-update). It is important to include which services are going to be down and for how long.
Sometimes teams misunderstand downtimes of Cloud Platform services also involve downtime of their services, so it is very handy being precise about the change.