Difference between revisions of "Globalyzer and Check in Verification"
(→Typical Workflow) |
|||
| Line 2: | Line 2: | ||
Some Application Lifecycle Management systems take automatic action when a developer checks in code and before the code is actually pushed to the authoritative repository. |
Some Application Lifecycle Management systems take automatic action when a developer checks in code and before the code is actually pushed to the authoritative repository. |
||
| − | Globalyzer clients can be integrated into an automatic commit checker. This allows i18n scanning of the newly committed files to a buffer area (not the authoritative repository). When developers check in their code, the newly committed files are checked for i18n candidate issues. Actions can be determined by the wrapping program around Globalyzer API or wrapping scripts around Globalyzer Lite |
+ | Globalyzer clients can be integrated into an automatic commit checker. This allows i18n scanning of the newly committed files to a buffer area (not the authoritative repository). When developers check in their code, the newly committed files are checked for i18n candidate issues. Actions can be determined by the wrapping program around Globalyzer API or wrapping scripts around Globalyzer Lite. |
One such action could be that if i18n issues are detected, an email is send to the committing developer with the attached file indicating the issues, and the committed files are not committed to the authoritative repository. Lite allows for that integration; Lingoport does not do that integration as each system is different. |
One such action could be that if i18n issues are detected, an email is send to the committing developer with the attached file indicating the issues, and the committed files are not committed to the authoritative repository. Lite allows for that integration; Lingoport does not do that integration as each system is different. |
||
| Line 15: | Line 15: | ||
= Typical Workflow= |
= Typical Workflow= |
||
| − | The automatic checker uses a Globalyzer client, such as |
+ | The automatic checker uses a Globalyzer client, such as calling Globalyzer Lite or a Java wrapper around the Globalyzer API, in order to: |
* Scan the code being worked on for potential i18n issues before checking in the code to the source code repository |
* Scan the code being worked on for potential i18n issues before checking in the code to the source code repository |
||
* Take the appropriate actions based on the scan results, such as preventing the committed code from being pushed to the authoritative repository and/or sending emails notifications. |
* Take the appropriate actions based on the scan results, such as preventing the committed code from being pushed to the authoritative repository and/or sending emails notifications. |
||
Revision as of 18:55, 2 September 2015
Introduction
Some Application Lifecycle Management systems take automatic action when a developer checks in code and before the code is actually pushed to the authoritative repository.
Globalyzer clients can be integrated into an automatic commit checker. This allows i18n scanning of the newly committed files to a buffer area (not the authoritative repository). When developers check in their code, the newly committed files are checked for i18n candidate issues. Actions can be determined by the wrapping program around Globalyzer API or wrapping scripts around Globalyzer Lite.
One such action could be that if i18n issues are detected, an email is send to the committing developer with the attached file indicating the issues, and the committed files are not committed to the authoritative repository. Lite allows for that integration; Lingoport does not do that integration as each system is different.
Target User
The typical user is a developer working on a global market application. The developer does not change the way code is written. When checking in the code, the i18n Gate will need to be configured to take the proper action, such as rejecting the commit and emailing to the developer.
Typical Deployment
Lite has been unzipped on the automatic checker system and configured in a script that runs on each commit to that intermediary zone. The source code has a Globalyzer project definition file at the top level directory which specifies how the code should be scanned.
Typical Workflow
The automatic checker uses a Globalyzer client, such as calling Globalyzer Lite or a Java wrapper around the Globalyzer API, in order to:
- Scan the code being worked on for potential i18n issues before checking in the code to the source code repository
- Take the appropriate actions based on the scan results, such as preventing the committed code from being pushed to the authoritative repository and/or sending emails notifications.
This requires the rule sets used to scan the code have been vetted.
