Commit 31e674b900f424d41ee9e533b038b66d325f77a4
1 parent
7027cecd
Exists in
master
and in
3 other branches
Improving merged version and adding team compositions
Showing
1 changed file
with
76 additions
and
99 deletions
Show diff stats
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 | +--> | ... | ... |