Download as
Browse Code »

Commit a9b24e57d104a7cba367a0d4622d4642ae9744d7

Authored by Paulo Meireles
1 parent 5317e8b5
Exists in master and in 3 other branches oss_2018, oss_2018_siqueira, rework_case_study

Last review

Showing 1 changed file with 71 additions and 69 deletions   Show diff stats
ieeeSW/releaseEng3/IEEE_ThemeIssue_ReleaseEng_CD.md
  Diff comments   View file @a9b24e5
... ... @@ -12,28 +12,31 @@ geometry: "left=1in,right=1.5in"
12 12 __Rodrigo Siqueira__ is a Computer Science MSc student at the Institute of
13 13 Mathematics and Statistics of the University of São Paulo (IME-USP). His
14 14 research interests include software engineering, operating system, and computer
15   -architecture. He worked for two years with the Brazilian federal government as
16   -a coach and developer. Contact him at siqueira@ime.usp.br.
17   -
18   -__Diego Camarinha__ is a CS MSc masters student at IME-USP. His research
19   -interests include software engineering, computer networks, and source code
20   -metrics. He worked for two years with the Brazilian federal government as a
21   -senior developer. Contact him at diegoamc@ime.usp.br.
22   -
23   -__Melissa Wen__ is a software developer. She worked on the SPB project as a
24   -senior developer and also served as a Computer Science lecturer at the Federal
25   -University of Bahia. Her areas of interest include software engineering and
26   -open source software development. Contact her at melissa.srw@gmail.com.
27   -
28   -__Paulo Meirelles__ received his Ph.D. in Computer Science from IME-USP. He is
29   -a full-time Professor at the University of Brasilia and coordinated the new SPB
30   -portal project. His research interests are: Free Software, Agile methods,
31   -Static analysis, and Source code metrics. Contact him at paulormm@ime.usp.br.
32   -
33   -__Fabio Kon__ is a Full Professor of Computer Science at IME-USP and
34   -Editor-in-Chief of the SpringerOpen Journal of Internet Services and
35   -Applications. His research interests include Agile Software Development, Smart
36   -Cities, and Distributed Systems. Contact him at fabio.kon@ime.usp.br.
  15 +architecture. He worked for two years with the SPB project as a coach and
  16 +developer. Contact him at siqueira@ime.usp.br.
  17 +
  18 +__Diego Camarinha__ is a Computer Science MSc masters student at IME-USP. His
  19 +research interests include software engineering, computer networks, and source
  20 +code metrics. He worked for two years with the SPB project as a senior
  21 +developer. Contact him at diegoamc@ime.usp.br.
  22 +
  23 +__Melissa Wen__ is a Computer Science MSc masters student at IME-USP. She
  24 +worked on the SPB project as a senior developer and was core developer of
  25 +Noosfero social networking platform at Colivre. Her areas of interest include
  26 +software engineering and open source software development. Contact her at
  27 +melissa@colivre.coop.br.
  28 +
  29 +__Paulo Meirelles__ is a full-time Professor of Software Engineering at the
  30 +University of Brasilia and researcher at the Free/Libre/Open Source Software
  31 +Competence Center (CCSL) at IME-USP. He was the head of the new SPB portal
  32 +development. His research interests include Free Software development, Agile
  33 +Software Development, and Source code metrics. Contact him at paulormm@unb.br.
  34 +
  35 +__Fabio Kon__ is a Full Professor of Computer Science at IME-USP, co-founder of
  36 +the CCSL at IME-USP, and Editor-in-Chief of the SpringerOpen Journal of
  37 +Internet Services and Applications. His research interests include Agile
  38 +Software Development, Smart Cities, and Distributed Systems. Contact him at
  39 +fabio.kon@ime.usp.br.
37 40  
38 41 ## Abstract
39 42  
... ... @@ -51,8 +54,8 @@ valuable for readers in a variety of situations.
51 54 From 2014 to 2016, we worked on a thirty-month-long Brazilian government
52 55 project to modernize the Brazilian Public Software (SPB) portal
53 56 (www.softwarepublico.gov.br) [1]. This project was a partnership between the
54   -_Ministry of Planning, Budget, and Management_ and two public universities:
55   -University of Brasília and University of São Paulo.
  57 +_Ministry of Planning, Budget, and Management (MPOG)_ and two public
  58 +universities: University of Brasília and University of São Paulo.
56 59  
57 60 During this time, the SPB portal evolved into a Collaborative Development
58 61 Environment (CDE), which brought significant benefits for the government and
... ... @@ -74,9 +77,9 @@ trust relationships is yet another of its benefits [2,3].
74 77  
75 78 SPB is a governmental program created to foster sharing and collaboration on
76 79 Open Source Software (OSS) development for the Brazilian public administration.
77   -The ministry managed both software requirements and server infrastructure.
78   -However, its hierarchical and traditional processes made them unfamiliar with
79   -new software development techniques, such as CD. All our requests had to pass
  80 +The MPOG managed both software requirements and server infrastructure. However,
  81 +its hierarchical and traditional processes made them unfamiliar with new
  82 +software development techniques, such as CD. All our requests had to pass
80 83 through layers of bureaucracy before being answered; accessing their
81 84 infrastructure to deploy software was not different. The difficulties were
82 85 aggravated because the new SPB portal is an unprecedented platform in the
... ... @@ -98,16 +101,16 @@ the government deployment process.
98 101 First, our development team was not the typical one, consisting mainly of
99 102 undergraduate interns supported by senior developers and designers, all
100 103 coordinated by two professors. Our unconventional team structure and
101   -organization was considered as "unprofessional" by ministry standards with
  104 +organization was considered as "unprofessional" by government standards with
102 105 regard to time and resource allocation, accountability, and team continuity.
103 106 On the government side, the SPB portal evolution was the first software
104   -development collaboration involving universities and the ministry staff,
105   -raising disbelief.
  107 +development collaboration involving universities and the MPOG staff, raising
  108 +disbelief.
106 109  
107 110 Second, our team approached software deployment differently from the
108 111 government. We believed frequent delivery is better for the project’s success.
109   -In contrast, the ministry is used to the idea of a single deployment at the end
110   -of the project, and neither their bureaucratic structure nor their technical
  112 +In contrast, the MPOG is used to the idea of a single deployment at the end of
  113 +the project, and neither their bureaucratic structure nor their technical
111 114 expertise was conducive to this style of work. That was hampering the benefits
112 115 of the tool and preventing us from showing off the fruits of the project to
113 116 those responsible for evaluating it.
... ... @@ -135,9 +138,9 @@ We built a system-of-systems [5] adapting and integrating five existing OSS
135 138 projects: Colab (www.github.com/colab), Noosfero (www.noosfero.org), Gitlab
136 139 (www.gitlab.com), Mezuro (www.mezuro.org), and Mailman (www.list.org). Colab
137 140 orchestrates these multiple systems using a plugin architecture and allowed us
138   -to smoothly provide a unified interface to final users, including SSO and
139   -global searches [1]. All these integrated systems involve a total of 106,253
140   -commits and 1,347,421 lines of code.
  141 +to smoothly provide a unified interface to final users, including single
  142 +sign-on and global searches [1]. All these integrated systems involve a total
  143 +of 106,253 commits and 1,347,421 lines of code.
141 144  
142 145 ![The SPB Deployment Pipeline.](figures/pipeline.png)
143 146  
... ... @@ -179,8 +182,8 @@ available for our deployment scripts.
179 182 ### Validation Environment
180 183  
181 184 The Validation Environment (VE) is a replica of the Production Environment (PE)
182   -with anonymised data, and access restricted to ministry staff and our DevOps
183   -team. To configure this environment, we used Chef (www.chef.io) and Chake, a
  185 +with anonymised data, and access restricted to MPOG staff and our DevOps team.
  186 +To configure this environment, we used Chef (www.chef.io) and Chake, a
184 187 serverless configuration tool created by our team
185 188 (www.github.com/terceiro/chake) to maintain environment consistency,
186 189 simplifying the deployment process.
... ... @@ -188,7 +191,7 @@ simplifying the deployment process.
188 191 ### Acceptance Tests
189 192  
190 193 After a new SPB portal VE deployment, we used the environment to verify the
191   -integrity of the entire portal. Government staff also checked the new features,
  194 +integrity of the entire portal. MPOG staff also checked the new features,
192 195 required changes, and bug fixes. If they identified a problem, they would
193 196 notify developers via comments on the SPB portal issue tracker, prompting the
194 197 team to fix it and restart the pipeline. Otherwise, we could move forward.
... ... @@ -215,13 +218,13 @@ benefits.
215 218  
216 219 ### Strengthening Trust in the Relationship with the Government
217 220  
218   -CD helped strengthen trust between developers and the government staff. Before
219   -using CD, they could validate features developed only at the end of the release
  221 +CD helped strengthen trust between developers and the MPOG staff. Before using
  222 +CD, they could validate features developed only at the end of the release
220 223 cycle, usually every four months. With the implementation of CD, intermediate
221 224 and candidate versions became available, allowing them to perform small
222 225 validations over time. Constant monitoring of the development work brought
223   -greater assurance to the ministry leaders and improved the interactions with
224   -our team.
  226 +greater assurance to the MPOG leaders and improved the interactions with our
  227 +team.
225 228  
226 229 ### Responsiveness to Change
227 230  
... ... @@ -238,13 +241,13 @@ confident that the project would last a little longer.
238 241  
239 242 ### Shared Responsibility
240 243  
241   -According to the conventional ministry process, the development team could not
  244 +According to the conventional MPOG process, the development team could not
242 245 track what happened to the code after its delivery, since their employees were
243 246 the only ones responsible for deployment. The implementation of CD made our
244 247 development team feel equally responsible for what was getting into production
245 248 and take ownership of the project [4].
246 249  
247   -Interestingly, the CD pipeline had the same effect on the ministry staff. They
  250 +Interestingly, the CD pipeline had the same effect on the MPOG staff. They
248 251 became more engaged in the whole process, opening and discussing issues during
249 252 the evolution of the platform. Additionally, developers worked to improve the
250 253 CD pipeline and speed up the process of making new features available in the
... ... @@ -253,19 +256,18 @@ production environment.
253 256 ### Synchronization Between Government and Development
254 257  
255 258 The CD pipeline performance depended on the synchronization between our
256   -development team and the ministry staff: each party had to be prepared to take
257   -action as soon as the other concluded a given task. Initially, the ministry
258   -staff did not contemplate this in their schedule which, combined with the
259   -bureaucracy in providing access to the PE (up to 3 days), resulted in
260   -significant delays in the validation of new features. The use of an explicit CD
261   -pipeline helped us to identify critical points of delay, and increase our
262   -productivity.
  259 +development team and the MPOG staff: each party had to be prepared to take
  260 +action as soon as the other concluded a given task. Initially, the MPOG staff
  261 +did not contemplate this in their schedule which, combined with the bureaucracy
  262 +in providing access to the PE (up to 3 days), resulted in significant delays in
  263 +the validation of new features. The use of an explicit CD pipeline helped us to
  264 +identify critical points of delay, and increase our productivity.
263 265  
264 266 ## Lessons Learned
265 267  
266 268 Due to the successful building of the CD pipeline, we not only overcame the
267   -challenges we described above but also improved the ministry deployment process
268   -and kept the project alive until its successful conclusion. We now look at the
  269 +challenges we described above but also improved the MPOG deployment process and
  270 +kept the project alive until its successful conclusion. We now look at the
269 271 lessons we learned, which can be leveraged by readers in other situations.
270 272  
271 273 ### Build CD From Scratch
... ... @@ -288,38 +290,38 @@ process on-the-fly.
288 290  
289 291 ### Overcoming Mistrust
290 292  
291   -Adopting an unfamiliar approach requires trust. ministry staff, traditionally,
  293 +Adopting an unfamiliar approach requires trust. MPOG staff, traditionally,
292 294 expected and were prepared to validate and deploy a single deliverable.
293 295 However, the steady growth of SPB complexity made large deliveries
294 296 unsustainable. The CD approach was necessary [4]. Therefore, we developed the
295 297 following line of action to enable this new dynamics:
296 298  
297 299 1. _Demonstrate actual results, instead of simply reporting them._ Initially,
298   -we did not have access to the ministry infrastructure, so we created our own
  300 +we did not have access to the government infrastructure, so we created our own
299 301 validation environment. Thus, we were able to follow the CD pipeline until
300 302 production deployment, when we faced two problems. First, our pace of
301 303 intermediate deliveries was faster than the deployment to production by the
302   -government staff. Second, specific issues of the governmental infrastructure
303   -made some validated features not work as expected in the PE. That situation
304   -gave us arguments to negotiate access to the PE.
  304 +MPOG staff. Second, specific issues of the governmental infrastructure made
  305 +some validated features not work as expected in the PE. That situation gave us
  306 +arguments to negotiate access to the PE.
305 307  
306 308 2. _Make project management transparent and collaborative for government
307   -staff._ Allowing the ministry staff to track our development process showed
308   -them we were fulfilling our commitments. They started to interact more actively
309   -in the generation of versions and became involved in the CD. After
310   -understanding it, the ministry staff helped us negotiate access to a VE with
311   -the ministry leaders, creating an isolated replica of the PE.
  309 +staff._ Allowing the MPOG staff to track our development process showed them we
  310 +were fulfilling our commitments. They started to interact more actively in the
  311 +generation of versions and became involved in the CD. After understanding it,
  312 +the MPOG staff helped us negotiate access to a VE with the MPOG leaders,
  313 +creating an isolated replica of the PE.
312 314  
313 315 3. _Gain the confidence of government staff._ With the PE replica, we were able
314   -to run the entire pipeline and win the trust of the ministry staff involved in
315   -the process. They saw the mobilization and responsiveness of our team to
316   -generate each new version package. They also recognized the quality of our work
317   -and deployment process. In the end, the ministry staff realized that it would
318   -be beneficial for the project if they granted us access to the infrastructure,
  316 +to run the entire pipeline and win the trust of the MPOG staff involved in the
  317 +process. They saw the mobilization and responsiveness of our team to generate
  318 +each new version package. They also recognized the quality of our work and
  319 +deployment process. In the end, the MPOG staff realized that it would be
  320 +beneficial for the project if they granted us access to the infrastructure,
319 321 both VE and PE.
320 322  
321 323 In summary, we encourage the use of a well-thought CD pipeline as a means to
322   -gain trust in software development projects with large organizations.
  324 +gain trust in software development projects with government organizations.
323 325  
324 326 ## References
325 327  
... ...