Merge branch 'master' of softwarepublico.gov.br:softwarepublico/articles

Paulo Meireles
2 parents 2a4624a9 fe6b39d5
Showing 1 changed file with 23 additions and 20 deletions Show diff stats
ieeeSW/releaseEng3/IEEE_ThemeIssue_ReleaseEng_CD.md
@@ -106,9 +106,10 @@ worst political crisis after the re-democratization in Brazil.
 ![Deployment Pipeline](figures/pipeline.png)
-Figure X represents our CD pipeline. After each release, we have defined a set
-of features we would develop to comply with government’s requirements and then
-we have followed this pipeline.
+The figure represents our CD pipeline: each release starts with specific
+requirements which are refined and improved during development as they go
+through each one of the steps until finally reach the production environment. 
+At this point a new set of requirements is built and a new release starts.
 ### Automated tests
@@ -116,30 +117,32 @@ we have followed this pipeline.
 [//]: # (TODO - Adicionar que as mudanças no Colab quebravam todos os plugins.)
 [//]: # (https://www.linux.com/blog/learn/chapter/dev-ops/2017/7/devops-fundamentals-part-3-continuous-delivery-and-deployment)
-The SPB portal is composed of a set of FOSS systems. All of them have their own
-automated test suite. So, we encouraged the teams to keep unit tests coverage
-high for each system. We implemented the systems integration using a plugin
-architecture and wrote integration tests to check if they were working
-properly. The plugin architecture made the PSPB’s components decoupled. That
-allowed us to be confident that changes on one system would not affect others.
-This characteristic allowed the test execution of only the component with
-changes instead of the entire system.
+Each one of the Portal's software components had their own test suite which
+the development teams were required to maintain and expand if possible. The 
+integration of all these software was based on a plugin architecture and, 
+again, each plugin with its test suite to ensure this level of the platform
+stability.
-Our CD’s first step was to execute each system’s automated test suite. If any
-error was found, the pipeline stopped and the developers were notified. Only
-after all tests passed we move to preparing the release.  Preparing a new
-release
+This two-level testing approach provided us the necessary speed and
+the trust that each software and the whole platform stability. By first running
+the software specific test suite we checked its stability and, if there was any
+errors, the developers were warned and the execution of the plugins test suite
+was not started.
+
+Only after all tests passed we move to the next step down the pipeline.
+
+### Preparing a new release
 Our release system was divided into two perspectives: the application and the
-PSPB. The application tag refers to the specific feature or bug fix and is a
-monotonically increasing. A new tag on any system yielded a new PSPB tag.
+SPB Portal. The application tag refers to the specific feature or bug fix and is a
+monotonically increasing. A new tag on any system yielded a new SPB Portal tag.
 When all tests passed for a given component, we manually created a new
 application tag for it. As a consequence, that automatically created a new tag
-for the PSPB. Notice that we have forks of the original softwares and, as
+for the SPB Portal. Notice that we have forks of the original softwares and, as
 consequence, we had different tag values.  Packaging
-The PSPB platform is running under the CentOS GNU/Linux distribution.
+The SPB Portal platform is running under the CentOS GNU/Linux distribution.
 Basically, packaging a software for that distribution has three steps: (1)
 write the script for the specific environment (RPM), (2) build the package, and
 (3) upload it to a package repository. We chose to package our components for
@@ -177,7 +180,7 @@ The VE was used by the government agents to validate new features and required
 changes. Also, the VE was useful to verify the integrity of the entire portal
 as part of the next step in the pipeline.  Acceptance Tests
-After we completely deploy a new PSPB version in the VE, the government agents
+After we completely deploy a new SPB Portal version in the VE, the government agents
 are responsible for checking features and/or bug fixes required by them. If the
 technicians identify a problem, they notify the developers, the problems are
 fixed and the pipeline restarts from scratch. If everything is validated, we