Download as
Browse Code »

Commit 1f3dd187813bc80db822cafea91a7021cd5cfcb1

Authored by Melissa Wen
1 parent 31e674b9
Exists in master and in 3 other branches oss_2018, oss_2018_siqueira, rework_case_study

[i3eSW] Discard suggestion

Showing 1 changed file with 16 additions and 17 deletions   Show diff stats
ieeeSW/releaseEng3/IEEE_ThemeIssue_ReleaseEng_CD.md
  Diff comments   View file @1f3dd18
... ... @@ -160,9 +160,8 @@ the pipeline to release new versions.
160 160 Each integrated system had to be tested with its own test suite. This was not
161 161 enough, however: we also had to test the platform as a whole. Given that the
162 162 plugins also have their own test suites and these suites assume a double role
163   -as both plugin tests and as integration tests. These tests provided us the
164   -performance and security needed to guarantee the stability of components and
165   -the platform. If any test suite failed, by either a test error or coverage
  163 +as both plugin tests and as integration tests.
  164 +If any test suite failed, by either a test error or coverage
166 165 reduction below a certain threshold, the process stopped. Only when all tests
167 166 passed, the pipeline proceeded to the step of release preparation.
168 167  
... ... @@ -170,7 +169,7 @@ passed, the pipeline proceeded to the step of release preparation.
170 169  
171 170 Each software component was hosted in a separate Git repository. A new release
172 171 of a component was tagged with a reference to a specific new feature or bug
173   -fix. SPB, as an integration project, had its own Git repository
  172 +fix. SPB had its own Git repository
174 173 (www.softwarepublico.gov.br/gitlab/softwarepublico). A SPB portal release was
175 174 an aggregate of releases of all of its components. When a new component release
176 175 passed all of the SPB integration tests, we manually created a corresponding
... ... @@ -183,9 +182,8 @@ packaging.
183 182 Our packaging software approach involves three steps: writing the script for
184 183 the specific environment, building the package, and uploading it to a package
185 184 repository. We decided to create separate packages for each system. Packaging
186   -makes it easy to manage software in a given distribution, simplifies
187   -deployment, follows the distribution's best practices, and enables
188   -configuration and permission control.
  185 +brings portability, simplifies deployment, and enables configuration and
  186 +permission control.
189 187  
190 188 After creating a new tag for a system, the developers informed our DevOps [4]
191 189 team and the packaging process began. A set of scripts fully automated the
... ... @@ -226,12 +224,14 @@ fixes were finally available to end users.
226 224 Research points out many CD advantages in the industry [2, 5], such as
227 225 accelerated time to market, building the right product, productivity and
228 226 efficiency improvements, stable releases, and better customer satisfaction.
  227 +
  228 +
229 229 Working with the government, we noticed the following additional benefits.
230 230  
231 231 ### Strengthening Trust in the Relationship with the Government
232 232  
233 233 CD helped strengthen trust in the relationship between developers and
234   -the Ministry staff. Before using CD, they had access to the features
  234 +the Ministry staff. Before using CD, they could validate features
235 235 developed only at the end of the release cycle, usually every four months.
236 236 With the implementation of CD, intermediate and candidate versions became
237 237 available, allowing them to perform small validations over time.
... ... @@ -240,18 +240,17 @@ Ministry leaders and improved the interactions with our team.
240 240  
241 241 ### Responsiveness to Change
242 242  
243   -Responsiveness was one of the direct benefits of adopting the CD pipeline. The
  243 +Responsiveness was one of the direct benefits of adopting the CD pipeline.
  244 +Political interests may change requirements and priorities at any time. The
244 245 ability to react quickly to changes requested by the Ministry was vital to the
245   -project’s survival for 30 months. These changes in requirements and priorities
246   -were mostly motivated by political interests. We noticed that if we took too
  246 +project’s survival for 30 months. We noticed that if we took too
247 247 long to meet their demands, they would threaten to reduce financial support and
248 248 even cancel the project.
249 249  
250 250 CD helped us keep the PE up-to-date, even with partial versions of a feature.
251 251 Therefore, we always had something to show on meetings, easying their
252   -concerns about the final delivery of the platform.
253   -For our team, CD made developers more
254   -confident that the project would last a little longer.
  252 +concerns about the final delivery of the platform. For our team, CD made
  253 +developers more confident that the project would last a little longer.
255 254  
256 255 ### Shared Responsibility
257 256  
... ... @@ -274,9 +273,9 @@ development team and the Ministry staff: each party had to be prepared to take
274 273 action as soon as the other concluded a given task. Initially, the Ministry
275 274 staff did not contemplate this in their schedule which, combined with the
276 275 bureaucracy in providing access to the PE (up to 3 days), resulted in
277   -significant delays in the validation of new features. This problem was
278   -softened when they realized the impact of these delays on the final product and
279   -decided to allocate revisions in their work schedule.
  276 +significant delays in the validation of new features. The clear use of CD
  277 +pipeline helped us to identify and solve key points of delay, and increase our
  278 +productivity.
280 279  
281 280 <!---
282 281 Fabio sugeriu Lessons Learned, mas vamos mostrar exemplos da revista para ele olhar.
... ...