BOS Translation Workflow 2.0
Update the current BOS translation workflow to remove "bos-translation" repository
Problem Description
Our current BOS translation workflow involve another repository (bos-translations) where we store the the PO files for every language that later, will be used by the Crowdin tool to provide the strings inside of them to be translated by the translation team group.
This workflow is obsolete considering that was defined in that way to avoid issues with Mercurial conflicts code management and now we're using Git where this issues don't happen so we can reduce the workflow complexity and remove the 'bos-translation' repository from it. Apart from that, that workflow was defined to separate releases of BOS code and translation releases so in that way you could decide if just deploy only translation changes.
Background
This workflow is inherit from five years ago when the company was using Mercurial as code control version and have some issues managing the conflicts in the PO files and include them in the release process, apart from to use Rosetta tool that it's not longer used and we have zombie code inside of the BOS repository.
It's causing that our current releases we need to orchestrate steps between different repositories.
Solution
Move the translation workflow to work directly with the BOS repository instead of 'bos-translations' repository to simplify the translation workflow and apply an easiest management using a 'translations' branch that it's going to be used by the Crowdin tool to create PRs targeting to the BOS 'dev' branch.
With that, we're removing the relation with 'bos-translation' repository in the translation workflow and we could delete it (one repository less to maintain).
To improve the current workflow we need to apply the next actions:
- Include POT file in the BOS repository
- Create an specific Github integration user to access to BOS repository with 'write' permission (just 'admin' to configure Webhooks)
- Create a 'translations' branch to configure Crowdin using BOS repository instead of 'bos-translations' repository.
- Reconfigure Jenkins translation job to perform the same actions on BOS repository instead of 'bos-translations'.
- Update configured Jenkins job to be executed after every commit that contains HTMLs files.
- Update documentation related to the translation workflow and the steps in the release process.
- Create a guide to define how to request Crowdin access, who should approve it, who should do it and how to do it.
Apart from that, could be great clean everything related to 'ebury-rosetta' library because it's not longer used.
Alternatives
We didn't any change before because translations are always risky topic and in case of failure have consequences for the email client communications. Taking this into account we could have two ways there:
- Let's still working in the same way as now, we're not going to improve the process but we're not assuming any risk.
- Let's one step more in the process and change the workflow to create a specific branch to each development needed. It's should be our last step but, apart from increase the complexity, could be risky considering that we're not familiarised with this possible workflow yet.
Caveats
This is an intermediate step to go in some months to the next level that should be one translation branch for each development that needs translations (if make sense). For that, we need to do analysis about how is going to impact in our daily tasks apart from the branch management.
Operation
The translation PR merge should be done by the BOS release manager to avoid coordination with translations that should be appears in the production environments.
About Crowdin tool management, at the moment, @jose.almuedo and @daniel.gordillo where the main managers to provide access to the tool but we'll define a Confluence guide about everything related to this stuff.
Security Impact
We need to create a new integration Github user specific to Crowdin that connect BOS repository with Crowdin tool with 'write' permissions but, just at the beginning, 'admin' permission it's necessary to allow configure the webhooks that are necessary to read changes in the BOS 'dev' branch and create PRs (from 'translations' to 'dev').
Also considering that the 'bos-translation' workflow is going to dissapears anyone needs to manage the accesses.
Performance Impact
This doesn't affect directly to the BOS code performance but yes to the release management, so we're going to avoid more possible human errors and have a better understand of translation workflow.
Developer Impact
Nothing relevant, just one permanent 'translations' branch is going to be used to create translations PRs automatically by the Crowdin tool. Also to take into account is that this change is appliable to EBO workflow and we can delete the 'eburyonline-translation' repository.
As we mentioned in the Operation section, this branch will be managed by the release manager.
Data Consumer Impact
Nothing is going to change at this point considering that isn't going to have any impact to the translation team, just for the BOS release management.
Deployment
We need to prepare the tasks in the order that appears in the 'Operation' section and involve to the DevOps in the Jenkins job changes. Also the last step, is remove the 'bos-translation' repository but after some period of contingency time in case that we need to apply rollback.
Dependencies
NA