Commit 4335c99beaac5c639ccbba05dd15d043f0fdb1f9
Exists in
master
and in
3 other branches
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
... | ... | @@ -106,9 +106,10 @@ worst political crisis after the re-democratization in Brazil. |
106 | 106 | |
107 | 107 |  |
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 | ... | ... |