Download as
Browse Code »

Commit 4617497c73fb90ed58c7e4ebc6b388587e5bc515

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

[i3eSW] Rechecking Fabio's comments

Showing 1 changed file with 24 additions and 17 deletions   Show diff stats
ieeeSW/releaseEng3/IEEE_ThemeIssue_ReleaseEng_CD.md
  Diff comments   View file @4617497
1 1 ---
2   -title: "Continuous Delivery: Building Trust in a Large-scale, Complex Government Organization"
  2 +title: "Continuous Delivery: Building Trust in a Large-scale, complex government organization"
3 3 papersize: a4
4 4 geometry: "left=1in,right=1.5in"
5 5 ---
... ... @@ -33,6 +33,7 @@ __Fabio Kon__ is Full Professor of the Department of Computer Science of the
33 33 University of São Paulo. (...) .His research interest areas are: (...). Contact
34 34 him at fabio.kon@ime.usp.br.
35 35  
  36 +<!-- Fabio: Esse resumo está não usual porque ele não resume o que o artigo apresenta. Ele serve como uma motivação apenas. Mas talvez podemos deixar assim pra ver o que acontece -->
36 37 ## Abstract
37 38  
38 39 For many software development teams, the first aspects that come to mind
... ... @@ -46,7 +47,7 @@ overcome them.
46 47 ## Introduction
47 48  
48 49 From 2014 to 2016, we were part of a team that worked on a thirty-month-long
49   -Brazilian government project to modernize the Brazilian Public Software (SPB)
  50 +Brazilian government project to modernize the Brazilian Public Software (SPB)
50 51 portal (www.softwarepublico.gov.br) [1]. This project was a partnership between
51 52 the Ministry of Planning, Budget, and Management and two public universities:
52 53 University of Brasília and University of São Paulo.
... ... @@ -106,7 +107,7 @@ development collaboration between universities and the Ministry staff involved,
106 107 raising disbelief.
107 108  
108 109 Secondly, our team approached software deployment differently from the
109   -Ministry. We believed frequent delivery is better for the project’s success.
  110 +Ministry. We believed frequent delivery is better for the project’s success.
110 111 In contrast, the Ministry is used to the idea of a single deployment at the end
111 112 of the project, and neither their bureaucratic structure nor their technical
112 113 expertise were conducive with this style of work. That ended up hampering the
... ... @@ -122,8 +123,8 @@ technical issue we could tackle in the short term. As a result, we worked to
122 123 deploy one version of the project onto our infrastructure and showed it to the
123 124 government evaluators. This strategy proved them we could efficiently provide
124 125 new features, fulfill their expectations regarding the delivery of the
125   -requirements, and incited them to demand the latest version to be deployed in
126   -the Ministry infrastructure. This efficiency generated more pressure on the IT
  126 +requirements, and incited them to demand that the latest version be deployed in
  127 +the Ministry infrastructure. This generated more pressure on the IT
127 128 department responsible for the deployment routines. With each CD cycle, we
128 129 gradually built a new relationship among all parties and, by the end of the
129 130 project, we became active participants in the deploy operations.
... ... @@ -146,12 +147,14 @@ practices, as presented in Figure 1. It started when new code arrived; and when
146 147 it reach the production environment, we would restart the pipeline to release
147 148 new versions.
148 149  
  150 +<!-- Fabio: Neste ponto eu já gostaria de ter uma ideia do tamanho do sistema [..] eu gostaria de ter outros números como linhas de código [x], quantidade de componentes[x], usuários desenvolvedores esperados[Temos acesso?], etc.-->
  151 +
149 152 ### Automated Tests
150 153  
151 154 Each integrated system had to be tested with its own test suite. This checking
152 155 was not enough, however: we even had to test the platform as a whole. Given
153 156 that the plugins also have their own test suites and these suites assume a
154   -double role as both plugin tests and as integration tests. If any test suite
  157 +double role as both plugin tests and as integration tests. If any test suite
155 158 failed, by either a test error or coverage reduction below a certain threshold,
156 159 the process stopped. Only when all tests passed, the pipeline proceeded to the
157 160 step of release preparation.
... ... @@ -172,9 +175,9 @@ this process, we started packaging.
172 175 After creating a new tag for a system, DevOps team starts the packaging process.
173 176 Packaging brings portability, simplifies deployment, and enables configuration
174 177 and permission control. Our packaging software approach involves building
175   -separate packages for each system in three steps: writing the script for the
  178 +separate packages for each system, in three steps: writing the script for the
176 179 specific environment, building the package, and uploading it to a package
177   -repository. A set of scripts fully automated these steps. When all of them ran
  180 +repository. A set of scripts fully automated these steps. When all them ran
178 181 successfully, the new packages would be ready and available for our deployment
179 182 scripts.
180 183  
... ... @@ -192,13 +195,13 @@ simplifying the deployment process.
192 195 After a new SPB portal deployment in the VE, we used the environment to verify
193 196 the integrity of the entire portal. In this step, Ministry staff also checked
194 197 the new features, required changes and bug fixes. If they identified a problem,
195   -they would notify the developers via comments on the SPB portal's issue tracker,
  198 +they would notify the developers via comments on the SPB portal issue tracker,
196 199 prompting the team to fix it and restart the pipeline. Otherwise, we could move
197 200 forward.
198 201  
199 202 ### Production Environment Deployment
200 203  
201   -After the VE check, we could finally begin the deployment in the PE, with the
  204 +After the VE check, we could finally begin the deployment in production, with the
202 205 same configuration management tool, scripts, and package versions as in the VE.
203 206 After the deploy was completed, both VE and PE were identical. At that point,
204 207 new features and bug fixes were finally available to end users.
... ... @@ -220,9 +223,9 @@ following additional benefits.
220 223  
221 224 CD helped strengthen trust in the relationship between developers and the
222 225 Ministry staff. Before using CD, they could validate features developed only at
223   -the end of the release cycle, usually every four months. With the
  226 +the end of the release cycle, usually every four months. With the
224 227 implementation of CD, intermediate and candidate versions became available,
225   -allowing them to perform small validations over time. Constant monitoring of
  228 +allowing them to perform small validations over time. Constant monitoring of
226 229 the development work brought greater security to the Ministry leaders and
227 230 improved the interactions with our team.
228 231  
... ... @@ -258,7 +261,7 @@ production environment.
258 261  
259 262 The CD pipeline performance depended on the synchronization between our
260 263 development team and the Ministry staff: each party had to be prepared to take
261   -action as soon as the other concluded a given task. Initially, the Ministry
  264 +action as soon as the other concluded a given task. Initially, the Ministry
262 265 staff did not contemplate this in their schedule which, combined with the
263 266 bureaucracy in providing access to the PE (up to 3 days), resulted in
264 267 significant delays in the validation of new features. The use of an explicit CD
... ... @@ -277,7 +280,7 @@ learned.
277 280  
278 281 ### Build CD From Scratch
279 282  
280   -Taking on the responsibility for implementing CD impacted the whole team. Most
  283 +Taking on the responsibility for implementing CD impacted the whole team. Most
281 284 of our team members did not have CD know-how, and we had few working hours
282 285 available to build the pipeline. The construction and maintenance of the CD
283 286 process were made possible by the key decisions to:
... ... @@ -295,15 +298,19 @@ process on-the-fly.
295 298  
296 299 ### Overcoming Mistrust
297 300  
298   -Adopting an unfamiliar approach requires trust. Ministry staff, traditionally, expected and were prepared to validate and deploy a single deliverable. However, the steady growth of SPB complexity made large deliveries unsustainable. The CD approach was necessary. Therefore, we use the following approaches to made this new dynamic in the Ministry possible:
  301 +Adopting an unfamiliar approach requires trust. Ministry staff, traditionally,
  302 +expected and were prepared to validate and deploy a single deliverable. However,
  303 +the steady growth of SPB complexity made large deliveries unsustainable. The CD
  304 +approach was necessary. Therefore, we use the following approaches to made this
  305 +new dynamic in the Ministry possible:
299 306  
300 307 1. _Demonstrate actual results, do not simply tell._ Initially, we did not have
301 308 access to the Ministry infrastructure, so we created our own validation
302   -environment. Thus, we were able to follow the CD pipeline until production
  309 +environment. Thus, we were able to follow the CD pipeline until production
303 310 deployment, when we faced two problems. First, our pace of intermediate
304 311 deliveries to the government was faster than the deployment to production by
305 312 the Ministry staff. Second, specific issues of the Ministry infrastructure made
306   -some validated features not work as expected in the PE. That situation gave us
  313 +some validated features not work as expected in the PE. That situation gave us
307 314 arguments to negotiate access to the PE.
308 315  
309 316 2. _Make project management transparent and collaborative for government
... ...