Download as
Browse Code »

Commit 6f79d27de1360e1fd817b216f684c33ed96881bf

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

Merging original and new context section

Showing 1 changed file with 73 additions and 59 deletions   Show diff stats
ieeeSW/releaseEng3/IEEE_ThemeIssue_ReleaseEng_CD.md
  Diff comments   View file @6f79d27
  1 +<!---
  2 +Comment: "Having Gov in the title may turn off some readers. Maybe a title something like "Case study adapting CI to a large-scale, complex government organization" would allow it to cross over to non-gov large orgs."
  3 +
  4 +Siqueira/Paulo: Ainda não chegamos a um título final, mas estamos em vias de convergir
  5 +-->
1 6 ---
2 7 title: "Title: Continuous Delivery: a tool to build trust in a large-scale, complex Government organization"
3 8 papersize: a4
... ... @@ -29,71 +34,80 @@ __Fabio Kon__ ...
29 34 For many software development teams, the first aspects that come to mind regarding Continuous Delivery (CD) are the operational challenges and the competitive benefits. In our experience, CD was much more: it was a survival technique. This article presents how and why we applied CD in a Brazilian Government project for the development of a Collaborative Development Environment (CDE), sharing the unconventional challenges we faced and the strategies used to overcome them.
30 35  
31 36 ## Introduction
  37 +<!---
  38 +Comment: "Generally, the piece comes across as part advertisement for CI and part challenges paper. The authors should figure out their message and make it punch."
  39 +
  40 +Siqueira/Paulo: Ao meu ver, a introdução deixa bem claro o nosso "punch" e o resto do texto a gente desenrola bem isso
  41 +-->
32 42  
33   -We worked on a three-year-long Brazilian government project to evolve an existing platform that had technical issues and lacked political support. In 2014, the Ministry of Planning, Budget, and Management (MP) initiated a project to modernize the The Brazilian Public Software (SPB) portal in partnership with two public universities: University of Brasilia (UnB) and University of São Paulo (USP). The SPB Portal (www.softwarepublico.gov.br) evolved to a Collaborative Development Environment [1] and this evolution brought important benefits not just to the Brazilian government, but also to society as a whole. It aims to minimize bureaucracy and reducing costs by encouraging the use of the same set of applications across different government agencies. The society also gained a mechanism of transparency and collaboration, since anyone can check the government expenses on software and contribute to project communities.
  43 +We worked on a three-year-long Brazilian government project to evolve an existing platform that had technical issues and lacked political support. In 2014, the Ministry of Planning, Budget, and Management (MP) initiated a project to modernize the The Brazilian Public Software (SPB) portal in partnership with two public universities: University of Brasilia (UnB) and University of São Paulo (USP). The SPB Portal (www.softwarepublico.gov.br) evolved to a Collaborative Development Environment [1] and this evolution brought important benefits not just to the Brazilian government, but also to society as a whole. It aims to minimize bureaucracy and costs by encouraging the use of the same set of applications across different government agencies. The society also gained a mechanism of transparency and collaboration, since anyone can check the government expenses on software and contribute to project communities.
34 44  
35 45 In this article, we discuss the use of Continuous Delivery (CD) during our experience as the academic partner in this project. We focus on how we managed to implement CD in a large institution with traditional values and how CD helped to build trust between the government and the development team. CD enabled us to clearly show our progress and earned us the government’s confidence that we could adequately fulfill their requests, becoming an essential aspect of our interaction with them. According to this experience, the use of CD as a tool to build such trust relationships is yet another of its benefits [2].
36 46  
37 47 ## Context
  48 +<!---
  49 +Comment: "Background/intro - This could be more streamlined and focused. Maybe center around a question such as - What is different between gov and non-gov context using your data as to illustrate then tie that to what you had to do in your CI process to address this gap."
  50 +
  51 +Paulo: Vamos discordar do revisor. O ponto não foi gov e não gov. Vamos esclarecer que o SPB foi algo particular mesmo, cheio de nuâncias.
  52 +-->
  53 +
  54 +The SPB is a program released in 2005 to foster sharing and collaboration on Open Source Software (OSS) projects for the public administration. A SPB solution is considered a public good and the Federal Government assumes some responsibilities related to its use. The first version of the SPB Portal was available in 2007 but since 2009 it has had several technical issues. This is an example of the consequences generated by the hierarchical and traditional processes and the lack of expertise of public agents, in particular their from the Brazilian Ministry of Planning (MP), in software development.
  55 +
  56 +<!---
  57 +Comment:
  58 +"The authors present 3 challenges in the intro and then go on to expand them. However, the expansion (line 21-43 in page 2), is has pints about all three challenges mixed together. It would be better I think to split it into one para for each challenge. "
  59 +
  60 +Siqueira/Paulo: Note que esse ponto gerou muita discussão e confusão. Mudei um pouco a estratégia de forma a responder o revisor e ao mesmo tempo tornar o texto mais fluido
  61 +-->
  62 +
  63 +The SPB evolution project started in 2014: a presidential election year and everyone involved was under pressure to show results. Even with the re-election of the Brazilian President, leaderships in governmental agencies ended up changing in 2015. Each one of them had different political agendas which affected the project's requirements previously approved. Besides that scenario of instability, we overcame three distinct issues: (1) achieving the goals which have guided the platform development, (2) widespread belief among the government agents that any project in partnership with a University is doomed to fail, and (3) the rudimentary and bureaucratic deployment approach in the MP infrastructure. Handling the interaction of these elements was challenging and the unstable Brazilian political scenario only made things worse.
  64 +
  65 +<!---
  66 +Comment:
  67 +
  68 +"Some more details about the project that was developed in terms of what the project did could be shared. Right now it just seems like some platform. I am not sure a platform that does what? And why were these 5 tools (Noosfero, Gitlab, Mailman, Mezuro and Colab) were integrated? What purpose did they each serve?"
  69 +
  70 +Siqueira/Paulo: Contamos essa história sem ter que entrar em detalhes aqui. Contudo, será preciso fazer a seção de pipeline harmonizar com isso
  71 +-->
  72 +
  73 +To achieve the SPB project goals, we projected the SPB Portal as a CDE with additional social features. Due to the complexity of creating such a system from scratch, we decided to evolute and integrate existing open source tools to build a system-of-systems [?]. We work on a number of distinct systems such as social and collaboration network, Git repository manager, mailing list, source code metric evaluation, and a systems integration platform [OPENSYM]. We create a solution that orchestrates systems and allowed us to smoothly provide a unified interface for final users, including single sign-on and global searches. For that, we had to learn how each system worked and to come up with ideas of how to integrate them as fast as possible, with a team of mostly inexperienced developers.
  74 +
  75 +<!---
  76 +Comment: "Can the authors provide some data as well? As I said this is a unique scenario and the community can greatly benefit. For example, how many devs at any given time, how many features/unit time (month/year), how frequently were releases made, how frequently did you meet with the client, how frequently did the requirements change are some example questions to which if we had data, it would place the study in greater context."
  77 +
  78 +Siqueira/Paulo: Mostramos parte dos dados aqui e mais na frente falamos da mudança dupla da diretoria tmb
  79 +-->
  80 +
  81 +<!---
  82 +Comment:
  83 +" In page 3, the authors say 10 SW components were integrated, but only 5 were presented in Page 2. I see in Page 3/4 that the authors mean that they used the the tools in page 2 to manage the building of the SW. But that is not clear. This needs to be clarified. "
  84 +
  85 +Siqueira/Paulo: Isso aqui também fica resolvido
  86 +-->
  87 +
  88 +Our team was not from a typical company, but consisted mainly of undergraduate students. This led to a vast diversity and quick turnover of members. We had 42 different software engineering undergraduate students during the project: 24 in 2014, 36 in 2015, and 20 in 2016. We also had 2 designers and 6 senior developers from the Brazilian open source communities in charge of handling complex tasks and transferring knowledge to the undergrads. Finally, we had 2 professors responsible for interacting with the Brazilian government and controlling political pressures applied to the project.
  89 +
  90 +Beyond these technical and organizational issues, we had to overcome strong political bias and relatively low budget. The project suffered significant interference from the board of directors because the SPB Portal represents an interface between government and society. In light of political interests, directors continually imposed changes to the platform while ignoring our technical advice. During 2015, Brazil faced a political crisis that impacted the SPB: the board of directors was changed twice and, with it, the vision of the project. New directors primarily focused on keeping their distance from previous administrations.
  91 +
  92 +<!---
  93 +Paulo: o segundo problema foi alterado em relação à primeira versão, mas a explicação não ficou muito diferente.
  94 +-->
  95 +
  96 +The second barrier we had to face was the widespread belief among the government agents that any project in partnership with a University is doomed to fail, which made interacting with us complicated. In particular, the SysAdmin team from the MP had low technical knowledge to deploy new versions of the new SPB Portal in a timely manner, hampering the benefits of the tool and preventing us from showing off the fruits of the project to those responsible for evaluating it. The requirement analysts from the MP were real representatives of the Brazilian government in the project and their role was to test new features, to provide feedback to the development team, and to report for the MP leaders. The SysAdmins in charge of managing the host machines wherein SPB Portal was running. They were, theoretically, responsible for deploying the project but the new SPB Portal was an unprecedented platform to Brazilian government, generating a complex deployment process for their.
  97 +
  98 +<!---
  99 +Paulo: o terceiro problema é novo em relação à primeira versão, mas na prática tínhamos tratado a questão
  100 +-->
  101 +
  102 +To overcame the deployment limitation, we realized we needed to take control over the deployment process. We used CD as a mean to fulfill the government expectations and to provide quick response to their requests, which were influenced most of the time by the uncertainties of the project's continuity. We believed we would keep the project alive, even in a politically unstable and technically complex scenario. For this reason, we focused on automating the deploy process and formed a specific team dedicated to the deployment process. This team was responsible for maturing our CD pipeline, giving us confidence and agility to comply with government requirements.
  103 +
  104 +<!---
  105 +"the article is missing the ah,ha moment. Was there something interesting that you learned (could be a small thing) that you use to adapt the CI process when applying it in a gov or large org context versus a smaller org? "
  106 +
  107 +Siqueira/Paulo: eis o AH-HA moment!
  108 +-->
38 109  
39   -The SPB is a program released in 2005 to foster sharing and collaboration on Open Source Software (OSS) projects for the public administration. A SPB solution is considered a public good and the Federal Government assumes some responsibilities related to its use. The first version of the SPB Portal was available in 2007 but since 2009 it has had several technical issues. This case is an example of the consequences of the hierarchical and traditional processes and the lack of expertise of public agents, in particular their from the Brazilian Ministry of Planning (MP), in software development for the Government.
40   -
41   -The SPB evolution project started in 2014: a presidential election year and everyone involved was under pressure to show results. Even with the re-election of the Brazilian President, leaderships in governmental agencies ended up changing in 2015. Each one of them had different political agendas which affected the project's requirements previously approved. Besides that scenario of instability, we overcame four distinct issues: (i) achieving the goals which have guided the platform development, (ii) the MP agents mindset which believes that projects with university usually ends with no results, (iii) communicating effectively with MP agents, and (iv) the rudimentary and bureaucratic deployment approach in the MP infrastructure. Handling the interaction of these elements was challenging and the unstable Brazilian political scenario only made things worse.
42   -
43   ---- To be continued ---
44   -
45   -To achieve the SPB project goals, we had to overcome strong political bias tied
46   -with complicated technical issues and relatively low budget. Because the
47   -project is open to the public, the government representatives saw the platform
48   -as a marketing opportunity and sometimes ignored technical advice in favor of
49   -political decisions. Furthermore, integrating a number of distinct systems
50   -(such as social and collaboration network, Git repository manager, mailing
51   -list, source code metric evaluation, and a systems integration platform) to
52   -work seamlessly was not an easy job. We had to learn how each system worked and
53   -to come up with ideas of how to integrate them as fast as possible, with a team
54   -of mostly inexperienced developers.
55   -
56   -We also had to manage the diversity of our team members. The team was composed
57   -of approximately 50 undergraduate students (not all simultaneously) together
58   -with professors, master students, professional designers and senior developers
59   -from the Brazilian free software community. Undergraduate students received a
60   -scholarship and, for most of them, this R&D project was their first
61   -professional experience. Senior developers and master students had two
62   -important contributions to the project: to transfer knowledge to undergraduate
63   -students and to deal with more complex tasks. Finally, professors were
64   -responsible for interacting with the Brazilian government and controlling
65   -political pressures applied to the project.
66   -
67   -Moreover, we needed to communicate with two independent groups of government
68   -representatives. Requirement analysts were real representatives of the
69   -Brazilian government in the project and their role was to test new features, to
70   -provide feedback to the development team, and to report to government leaders.
71   -Deployment technicians were in charge of managing the host machines wherein SPB
72   -platform was running. They were, theoretically, responsible for deploying the
73   -project. However, the new SPB Portal was composed of more than ten different
74   -software projects, working on seven servers, generating a complex deployment
75   -process.
76   -
77   -To handle the interaction between these three elements, we realised we needed
78   -to take control over the deployment process. We used CD as a mean to fulfill
79   -the government expectations and to provide quick response to their requests,
80   -which were influenced most of the time by the uncertainties of the project's
81   -continuity. We believed we would keep the project alive, even in a politically
82   -unstable and technically complex scenario. For this reason, we focused on
83   -automating the deploy process; for instance, one of our senior developers
84   -created a tool called Chake (www.gitlab.com/terceiro/chake) to help us manage
85   -multiple hosts without the need for a Chef-Server (www.chef.io/chef). We also
86   -formed a specific team dedicated to the deployment process. This team was
87   -responsible for maturing our CD pipeline, giving us confidence and agility to
88   -comply with government requirements.
89   -
90   -In this report, we describe our CD pipeline and how it improved our delivery
91   -performance. Continuous Delivery made us adaptable for all requested changes
92   -and helped us mitigate those aforementioned political challenges, besides the
93   -technical issues. Among CD’s known benefits [2] we also explain those which
94   -were the most important in our scenario: improving customer satisfaction and
95   -making reliable releases. Both kept the project alive for years during the
96   -worst political crisis after the re-democratization in Brazil.
  110 +These challenges made our relationship with the Government tense at the first year of the project, as well as, all political and technical issues alerted us for the fact that the project could be finished at any time if we could not overcome during the first year such problems. Therefore, the deployment limitation was the only real problem we could tackle in the short term. As a result, we worked to try and deploy one version of the project onto our own infrastructure and showed it to the government evaluators. This strategy proved them that we could efficiently deliver new features and fulfill their expectations and enticed them to demand these features in production. This, in turn, generated more pressure on the IT department responsible for the deployment routines. This was compounded with each CD cycle, allowing us to gradually built a new relationship among all parties and, by the end of the project, to become active participants in the deploy operations. CD kept the project alive for years during the worst political crisis after the re-democratization in Brazil.
97 111  
98 112 ## Our Continuous Delivery Pipeline
99 113  
... ...