Commit 31e674b900f424d41ee9e533b038b66d325f77a4

Authored by Paulo Meireles
1 parent 7027cecd

Improving merged version and adding team compositions

ieeeSW/releaseEng3/IEEE_ThemeIssue_ReleaseEng_CD.md
... ... @@ -52,25 +52,24 @@ the Ministry of Planning, Budget, and Management and two public universities:
52 52 University of Brasília and University of São Paulo.
53 53  
54 54 During this time, the SPB portal evolved into a Collaborative Development
55   -Environment (CDE) [2] which brought significant benefits for the government and
56   -the society: The government could minimize bureaucracy and software
57   -development costs, by reusing the same set of applications across
58   -different government agencies; society could more transparently
59   -follow government expenses and contribute to project
60   -communities.
  55 +Environment (CDE) which brought significant benefits for the government and the
  56 +society: The government could minimize bureaucracy and software development
  57 +costs, by reusing the same set of applications across different government
  58 +agencies; society could more transparently follow government expenses and
  59 +contribute to project communities.
61 60  
62 61 In this article, we discuss the use of Continuous Delivery (CD) during our
63 62 experience as the academic partner in this project. We focus on how we managed
64 63 to implement CD in a large institution with traditional values and how CD
65 64 helped to build trust between the government and the university development
66   -team. CD enabled us to show our progress and to earn the government’s confidence
67   -that we could adequately fulfill their requests, becoming an essential aspect
68   -of our interaction with them. According to this experience, the use of CD as a
69   -tool to build such trust relationships is yet another of its benefits [3].
  65 +team. CD enabled us to show our progress and to earn the government’s
  66 +confidence that we could adequately fulfill their requests, becoming an
  67 +essential aspect of our interaction with them. According to this experience,
  68 +the use of CD as a tool to build such trust relationships is yet another of its
  69 +benefits [2].
70 70  
71 71 ## Context
72 72  
73   -<!-- Avaliar se a descrição técnica sobre SPB não deveria vim aqui -->
74 73 SPB is a governmental program created to foster sharing and collaboration on
75 74 Open Source Software (OSS) development for the Brazilian public administration.
76 75 In their own projects, the Ministry managed both software requirements and server
... ... @@ -93,21 +92,13 @@ requirements previously approved.
93 92 mudar em todas as ocorrências de agents por staff, mas checar com o Fabio.
94 93 -->
95 94  
96   -In this context, we overcame three distinct challenges: (1) deconstructing
  95 +In this context, we overcame two distinct challenges: (1) deconstructing
97 96 the widespread belief among government staff that any project in partnership
98 97 with a University is doomed to fail, and (2) dealing with bureaucracies
99 98 involved in the deployment process.
100 99 <!-- Melissa: Acho que no segundo, seria bom falar: lidar com a aritmia que as burocracias do governo causavam ao nosso processo de deploy? -->
101 100  
102   -<!-- TODO:
103   -sugestão: Tira o primeiro challenge e acrescenta um texto no final desta
104   -seção dizendo "no final deu tudo certo: construímos uma ferramenta modular
105   -(inclui o conteúdo do parágrafo sobre o primeiro challenge) com uma equipe
106   -heterogênea (coloca a descrição das pessoas) e chegamos a um pacote com
107   -7 ferramentas blah blah blah
108   --->
109   -
110   -Firstly, our team was not from a typical company, consisting mainly of
  101 +Firstly, our team was not from a typical company, consisting from
111 102 undergraduate students coordinated by two professors. Accordingly, time and
112 103 resources allocation, accountability, and team continuity might be construed
113 104 as "unprofessional". On the government side, the SPB portal evolution was the
... ... @@ -146,43 +137,30 @@ team shrinked to 20 students, one designer, and two developers.
146 137 -->
147 138 ## Our Continuous Delivery Pipeline
148 139  
149   -SPB portal was designed as a CDE with additional social features. Due to the
150   -complexity of creating such a system from scratch, we decided to build
151   -system-of-systems, adapting and integrating five existing OSS projects - Colab,
152   -Noosfero, Gitlab, Mezuro, and Mailman. All integrated system represents a total
153   -of more than XXX.XXX commits and X.XXX.XXX lines of code. We created a solution
154   -that orchestrates multiple components and allowed us to smoothly provide a
155   -unified interface for final users, including single sign-on and global searches [1].
156   -
157   -<!--
158   -Melissa: avaliar se esse detalhamento é necessário para o texto
159   -These software component have different levels of complexity and size. Colab
160   -has had X commits which represent Y lines of code, Gitlab, 64.446 commits and
161   -502.597 lines, Noosfero, 14.175 commits and 607.490 lines, Mezuro, 9.007 commits
162   -and 217.828 lines, and, finally, Mailman with 19.101 commits and 180.871 lines.
163   -We can thus realize, with only the sum of the integrated projects, we have a
164   -platform that totals more than 106.729 commits and 1.508.786 lines of code.
165   --->
  140 +SPB portal was designed as a CDE with additional social features. We build
  141 +system-of-systems, adapting and integrating five existing OSS projects: Colab
  142 +(www.github.com/colab), Noosfero (www.noosfero.org), Gitlab (www.gitlab.com),
  143 +Mezuro (www.mezuro.org), and Mailman (www.list.org). All integrated system
  144 +represents a total of more than XXX.XXX commits and X.XXX.XXX lines of code.
  145 +That solution orchestrates these multiple components and allowed us to smoothly
  146 +provide a unified interface for final users, including single sign-on and
  147 +global searches [1].
166 148  
167 149 ![The SPB Deployment Pipeline](figures/pipeline_3.png)
168 150  
169   -Figure 1 presents our CD pipeline. It follows a typical deployment pipeline [3],
170   -adapted to the technical and organizational context of our project and the use
171   -of OSS best practices. The pipeline started when new code arrived. As the code
172   -went through each step, it was tested and improved until finally reaching the
173   -production environment. At this point, we would restart the pipeline to release
174   -new versions.
175   -
176   -<!---
177   -Comentário do Fábio: A partir daqui o texto já deveria mostrar o tamanho da plataforma e trazer dados que comprovem isso.
178   --->
  151 +The SPB portal deployment follows a typical CD pipeline [3], adapted to the
  152 +technical and organizational context of our project and the use of OSS best
  153 +practices, as presented in Figure 1. The pipeline started when new code
  154 +arrived. As the code went through each step, it was tested and improved until
  155 +finally reaching the production environment. At this point, we would restart
  156 +the pipeline to release new versions.
179 157  
180 158 ### Automated Tests
181 159  
182 160 Each integrated system had to be tested with its own test suite. This was not
183 161 enough, however: we also had to test the platform as a whole. Given that the
184   -plugins also have their own test suites and these suites assume a double role as
185   -both plugin tests and as integration tests. These tests provided us the
  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
186 164 performance and security needed to guarantee the stability of components and
187 165 the platform. If any test suite failed, by either a test error or coverage
188 166 reduction below a certain threshold, the process stopped. Only when all tests
... ... @@ -191,38 +169,37 @@ passed, the pipeline proceeded to the step of release preparation.
191 169 ### Preparing a New Release
192 170  
193 171 Each software component was hosted in a separate Git repository. A new release
194   -of a component was tagged with a reference to a specific new feature or bug fix.
195   -SPB, as an integration project, had its own Git repository. An SPB portal
196   -release was an aggregate of releases of all of its components. When a new
197   -component release passed all of the SPB integration tests, we manually created a
198   -corresponding new tag in its repository. Therefore, a new tag on any software
199   -component yielded a new SPB portal release. At the end of this process, we
200   -started packaging.
  172 +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
  174 +(www.softwarepublico.gov.br/gitlab/softwarepublico). A SPB portal release was
  175 +an aggregate of releases of all of its components. When a new component release
  176 +passed all of the SPB integration tests, we manually created a corresponding
  177 +new tag in its repository. Therefore, a new tag on any software component
  178 +yielded a new SPB portal release. At the end of this process, we started
  179 +packaging.
201 180  
202 181 ### Packaging
203 182  
204   -The platform runs on the CentOS 7 GNU/Linux distribution. Packaging software
205   -for that distribution involves three steps: writing the script for the specific
206   -environment (RPM), building the package, and uploading it to a package
207   -repository.
208   -
209   -We decided to create separate packages for each software component.
210   -Packaging makes it easy to manage software in a given distribution,
211   -simplifies deployment, follows the distribution's best practices, and
212   -enables configuration and permission control.
  183 +Our packaging software approach involves three steps: writing the script for
  184 +the specific environment, building the package, and uploading it to a package
  185 +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.
213 189  
214   -After creating a new tag for a component, the developers informed our DevOps
215   -[6] team and the packaging process began. A set of scripts fully automated the
216   -three packaging steps aforementioned. When all of them ran successfully, the new
217   -packages would be ready and available for our deployment scripts.
  190 +After creating a new tag for a system, the developers informed our DevOps [4]
  191 +team and the packaging process began. A set of scripts fully automated the
  192 +three packaging steps aforementioned. When all of them ran successfully, the
  193 +new packages would be ready and available for our deployment scripts.
218 194  
219 195 ### Validation Environment Deployment
220 196  
221 197 The Validation Environment (VE) is a replica of the Production Environment (PE)
222   -with anonymised data, and access restricted to Ministry staff and our DevOps team.
223   -To configure this environment, we used Chef (www.chef.io) and Chake, a serverless
224   -configuration tool created by our team (www.github.com/terceiro/chake). This
225   -maintained environment consistency, simplifying the deployment process.
  198 +with anonymised data, and access restricted to Ministry staff and our DevOps
  199 +team. To configure this environment, we used Chef (www.chef.io) and Chake, a
  200 +serverless configuration tool created by our team
  201 +(www.github.com/terceiro/chake). This maintained environment consistency,
  202 +simplifying the deployment process.
226 203  
227 204 The Ministry staff used the VE to validate new features and required changes.
228 205 The VE also was used to verify the integrity of the entire portal as part of
... ... @@ -246,7 +223,7 @@ fixes were finally available to end users.
246 223  
247 224 ## Benefits
248 225  
249   -Research points out many CD advantages in the industry [2, 7], such as
  226 +Research points out many CD advantages in the industry [2, 5], such as
250 227 accelerated time to market, building the right product, productivity and
251 228 efficiency improvements, stable releases, and better customer satisfaction.
252 229 Working with the government, we noticed the following additional benefits.
... ... @@ -286,21 +263,20 @@ and take ownership of the project.
286 263  
287 264 Interestingly, the CD pipeline had the same effect on the Ministry staff. They
288 265 became more engaged in the whole process, opening and discussing issues during
289   -the evolution of the platform. Additionally, developers worked to improve the CD pipeline
290   -and speed up the process of making new features available in the production
291   -environment.
  266 +the evolution of the platform. Additionally, developers worked to improve the
  267 +CD pipeline and speed up the process of making new features available in the
  268 +production environment.
292 269  
293 270 ### Synchronization Between Government and Development
294 271  
295 272 The CD pipeline performance depended on the synchronization between our
296   -development team and the Ministry staff: each party had to be prepared to
297   -take action as soon as the other concluded a given task.
298   -Initially, the Ministry staff did not contemplate this in their schedule which,
299   -combined with the bureaucracy in providing access to the PE
300   -(up to 3 days), resulted in significant delays in the validation of new features.
301   -This problem was softened when they realized the
302   -impact of these delays on the final product and decided to allocate
303   -revisions in their work schedule.
  273 +development team and the Ministry staff: each party had to be prepared to take
  274 +action as soon as the other concluded a given task. Initially, the Ministry
  275 +staff did not contemplate this in their schedule which, combined with the
  276 +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.
304 280  
305 281 <!---
306 282 Fabio sugeriu Lessons Learned, mas vamos mostrar exemplos da revista para ele olhar.
... ... @@ -313,10 +289,16 @@ deployment process and kept the project alive. We now look at the lessons learne
313 289  
314 290 ### Build CD From Scratch
315 291  
316   -Taking on the responsibility for implementing CD impacted the whole team.
317   -Most of our team members did not have CD know-how and we had few
318   -working hours available to build the pipeline. The construction
319   -and maintenance of the CD process were made possible by the key decisions to:
  292 +We started with a team composed of 24 undergraduate students, one designer, and
  293 +two senior developers. In 2015, our team grew to 36 students, two designers,
  294 +eight senior developers. For 2016, due to budget constraints, our team shrinked
  295 +to 20 students, one designer, and two developers; however, in the last 3
  296 +months, only 6 students closed the project.
  297 +
  298 +Taking on the responsibility for implementing CD impacted the whole team. Most
  299 +of our team members did not have CD know-how and we had few working hours
  300 +available to build the pipeline. The construction and maintenance of the CD
  301 +process were made possible by the key decisions to:
320 302  
321 303 <!---
322 304 pensar em generalizar/filosofar
... ... @@ -370,20 +352,15 @@ work and deployment process. In the end, the Ministry staff realized
370 352 that it would be beneficial for the project if they granted us access to the
371 353 infrastructure, both VE and PE.
372 354  
373   -<!---
374   -Paulo: Acho que precisamos de algo ligado ao Ha-Ha-moment para fechar o texto aqui; ou fechar falando que tudo foi feito de forma aberta e colaborativa com as comunidades dos projetos envolvidos, estão todos os fontes disponíveis em https://softwarepublico.gov.br/gitlab/softwarepublico/
375   -
376   -Melissa: Acho que não temos perna, mas podemos usar o gráfico como ah-ha
377   --->
378   -
379 355 ## References
380 356  
381 357 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.
382   -1. G. Booch and A. Brown, A. W. "Collaborative Development Environments", Advances in Computers, vol. 59, 2003, pp. 1-27.
383 358 1. L. Chen, "Continuous Delivery: Huge Benefits, but Challenges Too", IEEE Software, vol. 32, no. 2, 2015, pp. 50-54.
384   -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.
385 359 1. J. Humble and D. Farley, "Continuous Delivery: Reliable Software Releases Through Build, Test, and Deployment Automation", Addison-Wesley Professional, 2010.
386 360 1. J. Davis and K. Daniels, "Effective Devops: Building a Culture of Collaboration, Affinity, and Tooling at Scale", O'Reilly Media, Inc., 2016.
387 361 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.
388 362  
389   -
  363 +<!---
  364 +1. G. Booch and A. Brown, A. W. "Collaborative Development Environments", Advances in Computers, vol. 59, 2003, pp. 1-27.
  365 +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.
  366 +-->
... ...