Commit 5043606682d98a10ec14491755973d83ee9565e9
1 parent
86c42e50
Exists in
master
and in
3 other branches
Reword automated tests description
This needs a proper review since it has been written from scratch.
Showing
1 changed file
with
15 additions
and
13 deletions
Show diff stats
ieeeSW/releaseEng3/IEEE_ThemeIssue_ReleaseEng_CD.md
| @@ -118,19 +118,21 @@ At this point a new set of requirements is built and a new release starts. | @@ -118,19 +118,21 @@ At this point a new set of requirements is built and a new release starts. | ||
| 118 | [//]: # (TODO - Adicionar que as mudanças no Colab quebravam todos os plugins.) | 118 | [//]: # (TODO - Adicionar que as mudanças no Colab quebravam todos os plugins.) |
| 119 | [//]: # (https://www.linux.com/blog/learn/chapter/dev-ops/2017/7/devops-fundamentals-part-3-continuous-delivery-and-deployment) | 119 | [//]: # (https://www.linux.com/blog/learn/chapter/dev-ops/2017/7/devops-fundamentals-part-3-continuous-delivery-and-deployment) |
| 120 | 120 | ||
| 121 | -The SPB portal is composed of a set of FOSS systems. All of them have their own | ||
| 122 | -automated test suite. So, we encouraged the teams to keep unit tests coverage | ||
| 123 | -high for each system. We implemented the systems integration using a plugin | ||
| 124 | -architecture and wrote integration tests to check if they were working | ||
| 125 | -properly. The plugin architecture made the PSPB’s components decoupled. That | ||
| 126 | -allowed us to be confident that changes on one system would not affect others. | ||
| 127 | -This characteristic allowed the test execution of only the component with | ||
| 128 | -changes instead of the entire system. | ||
| 129 | - | ||
| 130 | -Our CD’s first step was to execute each system’s automated test suite. If any | ||
| 131 | -error was found, the pipeline stopped and the developers were notified. Only | ||
| 132 | -after all tests passed we move to preparing the release. Preparing a new | ||
| 133 | -release | 121 | +Each one of the Portal's software components had their own test suite which |
| 122 | +the development teams were required to maintain and expand if possible. The | ||
| 123 | +integration of all these software was based on a plugin architecture and, | ||
| 124 | +again, each plugin with its test suite to ensure this level of the platform | ||
| 125 | +stability. | ||
| 126 | + | ||
| 127 | +This two-level testing approach provided us the necessary speed and | ||
| 128 | +the trust that each software and the whole platform stability. By first running | ||
| 129 | +the software specific test suite we checked its stability and, if there was any | ||
| 130 | +errors, the developers were warned and the execution of the plugins test suite | ||
| 131 | +was not started. | ||
| 132 | + | ||
| 133 | +Only after all tests passed we move to the next step down the pipeline. | ||
| 134 | + | ||
| 135 | +### Preparing a new release | ||
| 134 | 136 | ||
| 135 | Our release system was divided into two perspectives: the application and the | 137 | Our release system was divided into two perspectives: the application and the |
| 136 | PSPB. The application tag refers to the specific feature or bug fix and is a | 138 | PSPB. The application tag refers to the specific feature or bug fix and is a |