Download as
Browse Code »

Commit 5043606682d98a10ec14491755973d83ee9565e9

Authored by Rafael Reggiani Manzo
1 parent 86c42e50
Exists in master and in 3 other branches oss_2018, oss_2018_siqueira, rework_case_study

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
  Diff comments   View file @5043606
... ... @@ -118,19 +118,21 @@ At this point a new set of requirements is built and a new release starts.
118 118 [//]: # (TODO - Adicionar que as mudanças no Colab quebravam todos os plugins.)
119 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 137 Our release system was divided into two perspectives: the application and the
136 138 PSPB. The application tag refers to the specific feature or bug fix and is a
... ...