Download as
Browse Code »

Commit 4335c99beaac5c639ccbba05dd15d043f0fdb1f9

Authored by Paulo Meireles
2 parents 2a4624a9 fe6b39d5
Exists in master and in 3 other branches oss_2018, oss_2018_siqueira, rework_case_study

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

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