Download as
Browse Code »

Commit 240bfef0ef92fda12deffd401d769cc2c708b403

Authored by Melissa Wen
2 parents 0371b378 354d2f82
Exists in master and in 3 other branches oss_2018, oss_2018_siqueira, rework_case_study

Merge branch 'ieee_new' of http://softwarepublico.gov.br/gitlab/softwarepublico/… 

…articles into ieee_new
Showing 1 changed file with 45 additions and 47 deletions   Show diff stats
ieeeSW/releaseEng3/IEEE_ThemeIssue_ReleaseEng_CD.md
  Diff comments   View file @240bfef
... ... @@ -41,10 +41,10 @@ him at fabio.kon@ime.usp.br.
41 41 For many software development teams, the first aspects that come to mind
42 42 regarding Continuous Delivery (CD) are the operational challenges and the
43 43 competitive benefits. In our experience, CD was much more: it was a survival
44   -technique. This article presents how and why we applied CD in a Brazilian
  44 +technique. This article presents how and why we applied CD in a large Brazilian
45 45 government project for the development of a Collaborative Development
46 46 Environment (CDE), sharing the challenges we faced and the strategies used to
47   -overcome them.
  47 +overcome them. ( >> FECHAR COM FRASE DE IMPACTO <<<).
48 48  
49 49 ## Introduction
50 50  
... ... @@ -69,7 +69,7 @@ team. CD enabled us to show our progress and to earn the government’s
69 69 confidence that we could adequately fulfill their requests, becoming an
70 70 essential aspect of our interaction with them. According to this experience,
71 71 the use of CD as a tool to build such trust relationships is yet another of its
72   -benefits [2].
  72 +benefits [2,3].
73 73  
74 74 ## Context
75 75  
... ... @@ -81,7 +81,7 @@ them unfamiliar with new software development techniques, such as CD. Any of
81 81 our requests had to pass through layers of bureaucracy before being answered;
82 82 accessing their infrastructure to deploy updated software was not different.
83 83 The difficulties were aggravated because the new SPB portal is an unprecedented
84   -platform in the Brazilian government, with a complicated deployment process.
  84 +platform in the Brazilian government, with a complicated deployment process [4].
85 85  
86 86 The project suffered significant interference from the board of directors
87 87 throughout time because the portal represents an interface between government
... ... @@ -100,15 +100,16 @@ the widespread belief among government staff that any project in partnership
100 100 with a University is doomed to fail, and (2) dealing with bureaucracies
101 101 involved in the Ministry deployment process.
102 102  
103   -Firstly, our team was not from a typical company, consisting mainly of
104   -undergraduate students supported senior developers and designers, all
105   -coordinated by two professors. Accordingly, time and resources allocation,
106   -accountability, and team continuity might be construed as "unprofessional". On
107   -the government side, the SPB portal evolution was the first software
108   -development collaboration between universities and the Ministry staff involved,
  103 +First, our development team was not from a typical company, consisting mainly
  104 +of undergraduate interns supported by senior developers and designers, all
  105 +coordinated by two professors. Our unconventional team structure and
  106 +organization might be considered as "unprofessional" by Ministry standards with
  107 +regard to time and resource allocation, accountability, and team continuity .
  108 +On the government side, the SPB portal evolution was the first software
  109 +development collaboration involving universities and the Ministry staff,
109 110 raising disbelief.
110 111  
111   -Secondly, our team approached software deployment differently from the
  112 +Second, our team approached software deployment differently from the
112 113 Ministry. We believed frequent delivery is better for the project’s success.
113 114 In contrast, the Ministry is used to the idea of a single deployment at the end
114 115 of the project, and neither their bureaucratic structure nor their technical
... ... @@ -116,17 +117,17 @@ expertise was conducive to this style of work. That ended up hampering the
116 117 benefits of the tool and preventing us from showing off the fruits of the
117 118 project to those responsible for evaluating it.
118 119  
119   -<!-- Melissa: tentar dividir esse último parágrafo em 2? Tá cansativo ler ele todo - não consigo respirar :P -->
  120 +<!-- AHA Moment!!!!! -->
120 121  
121 122 These challenges made our relationship with the Ministry staff tense, in
122 123 particular during the first year, and alerted us to the fact that they could
123   -finish the project at any time. The deployment limitation was the substantial
  124 +cancel the project at any time. The deployment limitation was the substantial
124 125 technical issue we could tackle in the short term. As a result, we worked to
125 126 deploy one version of the project onto our infrastructure and showed it to the
126 127 government evaluators. This strategy proved them we could efficiently provide
127 128 new features, fulfill their expectations regarding the delivery of the
128 129 requirements, and incited them to demand that the latest version be deployed in
129   -the Ministry infrastructure. This generated more pressure on the IT
  130 +the Ministry infrastructure. Our CD approach generated more pressure on the IT
130 131 department responsible for the deployment routines. With each CD cycle, we
131 132 gradually built a new relationship among all parties and, by the end of the
132 133 project, we became active participants in the deploy operations.
... ... @@ -134,33 +135,33 @@ project, we became active participants in the deploy operations.
134 135 ## Our Continuous Delivery Pipeline
135 136  
136 137 SPB portal is a CDE with additional social features, having 83 software
137   -communities and 6,460 users. We built system-of-systems adapting and
138   -integrating five existing OSS projects: Colab (www.github.com/colab), Noosfero
139   -(www.noosfero.org), Gitlab (www.gitlab.com), Mezuro (www.mezuro.org), and
140   -Mailman (www.list.org). Colab orchestrates these multiple components and
141   -allowed us to smoothly provide a unified interface for final users, including
142   -single sign-on and global searches [1]. All these integrated systems represents
143   -a total of 106.253 commits and 1.347.421 lines of code.
  138 +communities and 6,460 users, mostly government employees. We built
  139 +system-of-systems adapting and integrating five existing OSS projects: Colab
  140 +(www.github.com/colab), Noosfero (www.noosfero.org), Gitlab (www.gitlab.com),
  141 +Mezuro (www.mezuro.org), and
  142 +Mailman (www.list.org). Colab orchestrates these multiple systems using a
  143 +plugin architecture and allows us to smoothly provide a unified interface for
  144 +final users, including single sign-on and global searches [1]. All these
  145 +integrated systems represents a total of 106.253 commits and 1.347.421 lines of
  146 +code.
144 147  
145 148 ![The SPB Deployment Pipeline.](figures/pipeline.png)
146 149  
147   -The portal deployment follows a typical CD pipeline [3], adapted to the
  150 +The portal deployment follows a typical CD pipeline [5], adapted to the
148 151 technical and organizational context of our project and the use of OSS best
149 152 practices, as presented in Figure 1. It started when new code arrived; and when
150 153 it reaches the production environment, we would restart the pipeline to release
151 154 new versions.
152 155  
153   -<!-- 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. [atualmente, 83 softwares abrigado no portal?]-->
154   -
155 156 ### Automated Tests
156 157  
157   -Each integrated system had to be tested with its own test suite. This checking
158   -was not enough, however: we even had to test the platform as a whole. Given
159   -that the plugins also have their own test suites and these suites assume a
160   -double role as both plugin tests and as integration tests. If any test suite
161   -failed, by either a test error or coverage reduction below a certain threshold,
162   -the process stopped. Only when all tests passed, the pipeline proceeded to the
163   -step of release preparation.
  158 +In practice, each integrated system is a Colab plugin and had to be tested with
  159 +its own test suite. However, this checking was not enough: we also had to test
  160 +the platform as a whole. Since the plugins have their own test suites, they
  161 +also assume a double role as both plugin tests and as integration tests. If any
  162 +test suite failed, by either a test error or coverage reduction below a certain
  163 +threshold, the process stopped. Only when all tests passed, the pipeline
  164 +proceeded to the step of release preparation.
164 165  
165 166 ### Preparing a New Release
166 167  
... ... @@ -213,7 +214,7 @@ point, new features and bug fixes were finally available to end users.
213 214  
214 215 CD brings many advantages such as accelerated time to market, building the
215 216 right product, productivity and efficiency improvements, stable releases, and
216   -better customer satisfaction [2]. The charts presented in Figure 2 show these
  217 +better customer satisfaction [2,3]. The charts presented in Figure 2 show these
217 218 benefits of CD in our project and associates them with the creation of a DevOps
218 219 team. In the time of 30 months, we deployed a total of 84 versions. Over 64% of
219 220 these activities happened in the second half of 2015, with the DevOps team
... ... @@ -252,7 +253,7 @@ According to the conventional Ministry process, the development team could not
252 253 track what happened to the code after its delivery, since their staff was the
253 254 only ones responsible for deployment. The implementation of CD made our
254 255 development team feel equally responsible for what was getting into production
255   -and take ownership of the project.
  256 +and take ownership of the project [4].
256 257  
257 258 Interestingly, the CD pipeline had the same effect on the Ministry staff. They
258 259 became more engaged in the whole process, opening and discussing issues during
... ... @@ -277,6 +278,9 @@ Fabio sugeriu Lessons Learned, mas vamos mostrar exemplos da revista para ele ol
277 278  
278 279 ## Lessons Learned
279 280  
  281 +<!---
  282 +(>>>FABIO FAZER RELAÇÃO COM CHALLENGES DA SEÇÃO CONTEXTO<<<).
  283 +-->
280 284 Due to the successful building of the CD pipeline, we improved the Ministry
281 285 deployment process and kept the project alive. We now look at the lessons
282 286 learned.
... ... @@ -289,7 +293,7 @@ available to build the pipeline. The construction and maintenance of the CD
289 293 process were made possible by the key decisions to:
290 294  
291 295 1. _Select the most experienced senior developers and some advanced students of
292   -the project to work on a specific DevOps team._These senior developers used
  296 +the project to work on a specific DevOps team._ These senior developers used
293 297 their experience in OSS projects to craft an initial proposal for the
294 298 deployment process. The solution enabled us to automate the deployment, even
295 299 though the process was, initially, still rudimentary.
... ... @@ -304,7 +308,7 @@ process on-the-fly.
304 308 Adopting an unfamiliar approach requires trust. Ministry staff, traditionally,
305 309 expected and were prepared to validate and deploy a single deliverable. However,
306 310 the steady growth of SPB complexity made large deliveries unsustainable. The CD
307   -approach was necessary. Therefore, we developed the following line of action to
  311 +approach was necessary [4]. Therefore, we developed the following line of action to
308 312 make this new dynamics possible:
309 313  
310 314 1. _Demonstrate actual results, do not simply tell._ Initially, we did not have
... ... @@ -333,20 +337,14 @@ both VE and PE.
333 337  
334 338 ## References
335 339  
336   -1. P. Meirelles, M. Wen, A. Terceiro, R. Siqueira, L. Kanashiro, and H. Neri, "Brazilian Public Software Portal: an integrated platform for collaborative development", Proceedings of the 13th International Symposium on Open Collaboration. ACM, Article 16, 2017, 10 pages.
337   -1. L. Chen, "Continuous Delivery: Huge Benefits, but Challenges Too", IEEE Software, vol. 32, no. 2, 2015, pp. 50-54.
338   -1. J. Humble and D. Farley, "Continuous Delivery: Reliable Software Releases Through Build, Test, and Deployment Automation", Addison-Wesley Professional, 2010.
  340 +1. P. Meirelles, M. Wen, A. Terceiro, R. Siqueira, L. Kanashiro, and H. Neri, "Brazilian Public Software Portal: an integrated platform for collaborative development", OpenSym, 2017.
  341 +1. L. Chen, "Continuous Delivery: Huge Benefits, but Challenges Too", IEEE Software, 32 (2) 2015.
  342 +1. T. Savor, M. Douglas, M. Gentili, L. Williams, K. Beck and M. Stumm, "Continuous Deployment at Facebook and OANDA", ICSE, 2016.
  343 +1. M. Shahin, M. A. Babar, and L. Zhu. “The Intersection of Continuous Deployment and Architecting Process: Practitioners' Perspectives”. ESEM, 2016.
  344 +1. J. Humble and D. Farley, "Continuous Delivery: Reliable Software Releases Through Build, Test, and Deployment Automation", Addison-Wesley, 2010.
339 345  
340 346 <!---
341   -Citadas apenas para definir coisas já disseminadas
342   -1. G. Booch and A. Brown, A. W. "Collaborative Development Environments", Advances in Computers, vol. 59, 2003, pp. 1-27.
343 347 1. C. B. Nielsen, P. G. Larsen, J. Fitzgerald, J. Woodcock, and J. Peleska, "Systems of Systems Engineering: Basic Concepts, Model-Based Techniques, and Research Directions", ACM Comput. Surv. 48, 2, Article 18, 2015, 41 pages.
344   -1. J. Davis and K. Daniels, "Effective Devops: Building a Culture of Collaboration, Affinity, and Tooling at Scale", O'Reilly Media, Inc., 2016.
  348 +-->
345 349  
346   -Estava citada apenas na introdução dos benefícios
347   -1. T. Savor, M. Douglas, M. Gentili, L. Williams, K. Beck and M. Stumm, "Continuous Deployment at Facebook and OANDA", 2016 IEEE/ACM 38th International Conference on Software Engineering Companion (ICSE-C), Austin, TX, 2016, pp. 21-30.
348 350  
349   -Considerar:
350   -2017 State of DevOps Report
351   -https://puppet.com/resources/whitepaper/state-of-devops-report
352   --->
... ...