Download as
Browse Code »

Commit f537aec0d6e4a7b6b1cae7149a15120fa5990ccc

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

[i3eSW] Grammarly

Showing 1 changed file with 24 additions and 25 deletions   Show diff stats
ieeeSW/releaseEng3/IEEE_ThemeIssue_ReleaseEng_CD.md
  Diff comments   View file @f537aec
... ... @@ -101,7 +101,7 @@ involved in the deployment process.
101 101 Firstly, our team was not from a typical company, consisting mainly of
102 102 undergraduate students supported senior developers and designers, all coordinated by two professors. Accordingly, time and
103 103 resources allocation, accountability, and team continuity might be construed
104   -as "unprofessional". On the government side, the SPB portal evolution was the
  104 +as "unprofessional." On the government side, the SPB portal evolution was the
105 105 first software development collaboration between universities and the Ministry
106 106 staff involved, raising disbelief.
107 107  
... ... @@ -109,7 +109,7 @@ Secondly, our team approached software deployment differently from the Ministry.
109 109 We believed frequent delivery is better for the project’s success. In contrast,
110 110 the Ministry is used to the idea of a single deployment at the end of the
111 111 project, and neither their bureaucratic structure nor their technical expertise
112   -were conductive with this style of work. That ended up hampering the benefits of
  112 +were conducive with this style of work. That ended up hampering the benefits of
113 113 the tool and preventing us from showing off the fruits of the project to those
114 114 responsible for evaluating it.
115 115  
... ... @@ -123,7 +123,7 @@ deploy one version of the project onto our infrastructure and showed it to the
123 123 government evaluators. This strategy proved them we could efficiently provide
124 124 new features, fulfill their expectations regarding the delivery of the
125 125 requirements, and incited them to demand the latest version to be deployed in
126   -the Ministry infrastructure. This generated more pressure on the IT department
  126 +the Ministry infrastructure. This efficiency generated more pressure on the IT department
127 127 responsible for the deployment routines. With each CD cycle, we gradually built
128 128 a new relationship among all parties and, by the end of the project, we became
129 129 active participants in the deploy operations.
... ... @@ -137,12 +137,12 @@ team shrinked to 20 students, one designer, and two developers.
137 137 -->
138 138 ## Our Continuous Delivery Pipeline
139 139  
140   -SPB portal was designed as a CDE with additional social features. We build
  140 +SPB portal is a CDE with additional social features. We built
141 141 system-of-systems, adapting and integrating five existing OSS projects: Colab
142 142 (www.github.com/colab), Noosfero (www.noosfero.org), Gitlab (www.gitlab.com),
143 143 Mezuro (www.mezuro.org), and Mailman (www.list.org). All integrated system
144 144 represents a total of more than 106.253 commits and 1.347.421 lines of code.
145   -That solution orchestrates these multiple components and allowed us to smoothly
  145 +That solution orchestrated these multiple components and allowed us to smoothly
146 146 provide a unified interface for final users, including single sign-on and
147 147 global searches [1].
148 148  
... ... @@ -154,8 +154,8 @@ practices, as presented in Figure 1.
154 154  
155 155 ### Automated Tests
156 156  
157   -Each integrated system had to be tested with its own test suite. This was not
158   -enough, however: we also had to test the platform as a whole. Given that the
  157 +Each integrated system had to be tested with its own test suite. This checking was not
  158 +enough, however: we even had to test the platform as a whole. Given that the
159 159 plugins also have their own test suites and these suites assume a double role
160 160 as both plugin tests and as integration tests.
161 161 If any test suite failed, by either a test error or coverage
... ... @@ -165,10 +165,10 @@ passed, the pipeline proceeded to the step of release preparation.
165 165 ### Preparing a New Release
166 166  
167 167 Each software component was hosted in a separate Git repository. A new release
168   -of a component was tagged with a reference to a specific new feature or bug
  168 +of a component was tagged referencing a specific new feature or bug
169 169 fix. SPB had its own Git repository
170   -(www.softwarepublico.gov.br/gitlab/softwarepublico). A SPB portal release was
171   -an aggregate of releases of all of its components. When a new component release
  170 +(www.softwarepublico.gov.br/gitlab/softwarepublico). An SPB portal release was
  171 +an aggregate of versions of all of its components. When a new component release
172 172 passed all of the SPB integration tests, we manually created a corresponding
173 173 new tag in its repository. Therefore, a new tag on any software component
174 174 yielded a new SPB portal release. At the end of this process, we started
... ... @@ -183,7 +183,7 @@ brings portability, simplifies deployment, and enables configuration and
183 183 permission control.
184 184  
185 185 After creating a new tag for a system, the developers informed our DevOps [4]
186   -team and the packaging process began. A set of scripts fully automated the
  186 +team, and the packaging process began. A set of scripts fully automated the
187 187 three packaging steps aforementioned. When all of them ran successfully, the
188 188 new packages would be ready and available for our deployment scripts.
189 189  
... ... @@ -193,7 +193,7 @@ The Validation Environment (VE) is a replica of the Production Environment (PE)
193 193 with anonymised data, and access restricted to Ministry staff and our DevOps
194 194 team. To configure this environment, we used Chef (www.chef.io) and Chake, a
195 195 serverless configuration tool created by our team
196   -(www.github.com/terceiro/chake). This maintained environment consistency,
  196 +(www.github.com/terceiro/chake). This tool maintained environment consistency,
197 197 simplifying the deployment process.
198 198  
199 199 The Ministry staff used the VE to validate new features and required changes.
... ... @@ -202,7 +202,7 @@ the next step in the pipeline.
202 202  
203 203 ### Acceptance Tests
204 204  
205   -After a new SPB portal deployment in the VE, the Ministry were
  205 +After a new SPB portal deployment in the VE, the Ministry was
206 206 responsible for checking the required features and bug fixes. If they
207 207 identified a problem, they would notify the developers via
208 208 comments on the SPB portal's issue tracker, prompting the team to fix
... ... @@ -227,8 +227,7 @@ project and associates them with the creation of a DevOps team.
227 227 ![The evolution of SPB releases and the team members distribution in the period.](figures/CDReleaseAndTeamEvolution.png)
228 228  
229 229 In the time of 30 months, we deployed a total of 84 versions. Over 64% of these
230   -activities happened in the second half of 2015, when the DevOps team was
231   -created. Even with the reduction of the team as a whole, in the last months of
  230 +activities happened in the second half of 2015, with the DevOps team creation. Even with the reduction of the team as a whole, in the last months of
232 231 the project, this pace of deployment was maintained until we finished all our
233 232 activities.
234 233  
... ... @@ -255,14 +254,14 @@ long to meet their demands, they would threaten to reduce financial support and
255 254 even cancel the project.
256 255  
257 256 CD helped us keep the PE up-to-date, even with partial versions of a feature.
258   -Therefore, we always had something to show on meetings, easying their
  257 +Therefore, we always had something to show on meetings, easing their
259 258 concerns about the final delivery of the platform. For our team, CD made
260 259 developers more confident that the project would last a little longer.
261 260  
262 261 ### Shared Responsibility
263 262  
264 263 According to the conventional Ministry process, the development team could not
265   -track what happened to the code after its delivery, since their staff were
  264 +track what happened to the code after its delivery, since their staff was
266 265 the only ones responsible for deployment. The implementation of CD made our
267 266 development team feel equally responsible for what was getting into production
268 267 and take ownership of the project.
... ... @@ -280,8 +279,8 @@ development team and the Ministry staff: each party had to be prepared to take
280 279 action as soon as the other concluded a given task. Initially, the Ministry
281 280 staff did not contemplate this in their schedule which, combined with the
282 281 bureaucracy in providing access to the PE (up to 3 days), resulted in
283   -significant delays in the validation of new features. The clear use of CD
284   -pipeline helped us to identify and solve key points of delay, and increase our
  282 +significant delays in the validation of new features. The use of an explicit CD
  283 +pipeline helped us to identify critical points of delay, and increase our
285 284 productivity.
286 285  
287 286 <!---
... ... @@ -304,7 +303,7 @@ months, only 6 students closed the project.
304 303 -->
305 304  
306 305 Taking on the responsibility for implementing CD impacted the whole team. Most
307   -of our team members did not have CD know-how and we had few working hours
  306 +of our team members did not have CD know-how, and we had few working hours
308 307 available to build the pipeline. The construction and maintenance of the CD
309 308 process were made possible by the key decisions to:
310 309  
... ... @@ -327,8 +326,8 @@ evolving the process on-the-fly.
327 326  
328 327 <!-- Precisa 'dessuavizar' o porque das mudanças de requisitos - a motivação para ela não era tão natural como as que ocorrem em métodos ágeis -->
329 328 Adopting an unfamiliar approach requires trust. In the Ministry, traditionally,
330   -software was the product delivered at the end of a development contract; they
331   -expected and were prepared to validate and deploy a single deliverable. This
  329 +a software was the product delivered at the end of a development contract; they
  330 +expected and were prepared to validate and deploy a single deliverable. This process
332 331 was not adequate for the SPB: because the SPB portal is a system-of-systems,
333 332 the steady growth of its complexity made large deliveries unsustainable.
334 333 Therefore, the CD approach was necessary, but how
... ... @@ -344,8 +343,8 @@ production by the Ministry staff. Second, specific issues of the Ministry
344 343 infrastructure made some validated features not work as expected in the PE.
345 344 That situation gave us arguments to negotiate access to the PE.
346 345  
347   -2. _Make project management transparent and collaborative for government
348   -staff._ Allowing the Ministry staff to track our development process showed them
  346 +2. _Make project management transparent and collaborative for government staff._
  347 +Allowing the Ministry staff to track our development process showed them
349 348 we were fulfilling our commitments. They started to interact more actively in
350 349 the generation of versions and became involved in the CD. After understanding it,
351 350 the Ministry staff helped us negotiate access to a VE with the Ministry leaders,
... ... @@ -357,7 +356,7 @@ involved in the process. They saw the mobilization and responsiveness of our
357 356 team to generate each new version package. They also recognized the quality of our
358 357 work and deployment process. In the end, the Ministry staff realized
359 358 that it would be beneficial for the project if they granted us access to the
360   -infrastructure, both VE and PE.
  359 +infrastructure, both VE, and PE.
361 360  
362 361 ## References
363 362  
... ...