Merge branch 'master' of http://softwarepublico.gov.br/gitlab/softwarepublico/articles

Melissa Wen
2 parents 1acbfcf7 6c797374
Showing 1 changed file with 65 additions and 70 deletions Show diff stats
ieeeSW/releaseEng3/IEEE_ThemeIssue_ReleaseEng_CD.md
@@ -3,99 +3,94 @@
 ## Abstract
 For many software development teams, the first things that come to mind
-regarding Continuous Delivery (CD) are the operational aspects and the competitive
-benefits. In our experience, it was much more: it was a survival technique. This article
-presents how we applied CD in a Brazilian Government project for the
-development of a Collaborative Development Environment (CDE), sharing its
-unconventional challenges and the strategies used to overcome them. This report
-from the trench of the Brazilian Federal Government can help practitioners to
-understand how important CD adoption is to their projects.
+regarding Continuous Delivery (CD) are the operational aspects and the
+competitive benefits. In our experience, it was much more: it was a survival
+technique. This article presents how we applied CD in a Brazilian Government
+project for the development of a Collaborative Development Environment (CDE),
+sharing its unconventional challenges and the strategies used to overcome them.
+This report from the trench of the Brazilian Federal Government can help
+practitioners to understand how important CD adoption is to their projects.
 ## Introduction and Context
 We worked on a three-year-long Brazilian government project to evolve an
-existing platform that had technical issues and lacked political support.  The
-evolution project started in a presidential election year and everyone involved
-were under pressure to show results. Even with the re-election of the Brazilian
-President in 2014, leaderships in governmental agencies ended up changing. Each
-one of them had different political agendas which affected the project's
-requirements previously approved. Despite this scenario of instability, we
-managed to avoid delays in the delivery schedule and to prevent the project's
-cancellation.
-
-Our team from the University of Brasília (UnB) and the University of São Paulo
+existing platform that had technical issues and lacked political support.  Our
+team from the University of Brasília (UnB) and the University of São Paulo
 (USP) developed the new platform for the Brazilian Public Software (SPB,
-Portuguese acronym) Portal (www.softwarepublico.gov.br) from 2014 to 2016. The
-SPB Portal evolved to a Collaborative Development Environment [1] and this
-evolution brought about important benefits not just to the Brazilian
-government, but also to society as a whole.  For the government, the
-bureaucracy on using the same software across governmental agencies, duplicate
-works, and costs all were reduced. The society gained a transparency and
-collaboration mechanism, since anyone can check the government expenses on
-software and contribute to the software communities. To achieve these goals,
-rather than writing everything from scratch, we decided to integrate several
-free software tools such as Gitlab (www.gitlab.com), Mailman
+Portuguese acronym) Portal from 2014 to 2016. 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. For the government, the bureaucracy
+of using the same software across governmental agencies and the cost of
+developing similar software projects were all reduced. The society gained a
+transparent and collaborative mechanism, since anyone can check the government
+expenses on software and contribute to project communities. To achieve these
+goals, rather than writing everything from scratch, we decided to integrate
+several free software tools such as Gitlab (www.gitlab.com), Mailman
 (www.gnu.org/software/mailman), Noosfero (www.noosfero.org), and Colab
 (www.github.com/colab).
-During the entire SPB Portal evolution project, we had to handle three distinct
-issues, usual in a software engineering scenario: achieving the goals which have
-guided the platform development, managing the diversity of team project
-members, and communicating effectively with clients (in this case,
-government agents). Handling the interaction of these elements was not easy and
-the unstable Brazilian political scenario only made things worse.
+The project started in a presidential election year and everyone involved was
+under pressure to show results. Even with the re-election of the Brazilian
+President in 2014, leaderships in governmental agencies ended up changing. 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: (i) achieving the goals which have guided the
+platform development, (ii) managing the diversity of team members, and (iii)
+communicating effectively with government agents (our "clients"). Handling the
+interaction of these elements was challenging and the unstable Brazilian
+political scenario only made things worse.
 To achieve the SPB project goals, we had to overcome strong political bias tied
-with complicated technical issues and relatively low budget. Because it
-is open to the public, the government representatives saw the platform as a
-marketing opportunity and sometimes ignored technical advice in favor of
+with complicated technical issues and relatively low budget. Because the
+project is open to the public, the government representatives saw the platform
+as a marketing opportunity and sometimes ignored technical advice in favor of
 political decisions. Furthermore, integrating a number of distinct systems to
 work seamlessly was not an easy job. 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.
-We also had to manage the diversity of the SPB team members. This team was
-composed of approximately 50 undergraduate students (not all simultaneously)
-together with professors, masters students, professional designers and
-senior developers from the Brazilian free software community. Undergraduate
-students received a scholarship and, for most of them, this R&D project was
-their first professional experience. Seniors developers and masters students
-had two important contributions to the project: transfer knowledge to
-undergraduate students and address hard tasks. Finally, professors were
-responsible for interacting with the Brazilian government and controlling the
-political pressures applied to the project.
-
-The third point to be handled was the communication with two independent groups
-of government representatives: requirements analysts and deployment
-technicians. Requirements analysts were the 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
-government leaders. Deployment technicians were in charge of administering the host
-machines wherein SPB platform was running. They were, theoretically,
-responsible for deploying the project. However, the new SPB Portal was composed
-of more than ten different software projects, generating a complex deployment
-process, for instance, working on seven servers.
+We also had to manage the diversity of our team members. The team was composed
+of approximately 50 undergraduate students (not all simultaneously) together
+with professors, master students, professional designers and senior developers
+from the Brazilian free software community. Undergraduate students received a
+scholarship and, for most of them, this R&D project was their first
+professional experience. Senior developers and master students had two
+important contributions to the project: transfer knowledge to undergraduate
+students and more complex tasks. Finally, professors were responsible for
+interacting with the Brazilian government and controlling political pressures
+applied to the project.
+
+Moreover, we needed to communicate with two independent groups of government
+representatives. Requirement analysts 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 to government leaders.
+Deployment technicians were in charge of managing the host machines wherein SPB
+platform was running. They were, theoretically, responsible for deploying the
+project. However, the new SPB Portal was composed of more than ten different
+software projects, working on seven servers, generating a complex deployment
+process.
 To handle the interaction between these three elements, we realised 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 worked hard to
-automate the deploy process; for instance, one of our senior developers created
-a Chef-Server (www.chef.io/chef) front-end tool called Chake
-(www.gitlab.com/terceiro/chake) to help us to manage the multiple hosts needed
-for the project.  We also formed a specific team dedicated to the deployment
+unstable and technically complex scenario.  For this reason, we focused on
+automating automate the deploy process; for instance, one of our senior
+developers created a Chef-Server (www.chef.io/chef) front-end tool called Chake
+(www.gitlab.com/terceiro/chake) to help us manage the multiple hosts needed for
+the project.  We also 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.
 In this report, we describe our CD pipeline and how it improved our delivery
-performance.  The CD made us adaptable for all requested changes and helped us
-mitigate those aforementioned political challenges, besides the technical
-issues. Among CD’s known benefits [2], we also explain those which were the most
-important in the project scenario for us: improving customer satisfaction and
-making reliable releases. Both kept the project alive for more two years during
-the worst political crisis after the re-democratization in Brazil.
+performance. Continuous Delivery made us adaptable for all requested changes
+and helped us mitigate those aforementioned political challenges, besides the
+technical issues. Among CD’s known benefits [2] we also explain those which
+were the most important in our scenario: improving customer satisfaction and
+making reliable releases. Both kept the project alive for years during the
+worst political crisis after the re-democratization in Brazil.
 ## Our Continuous Delivery Pipeline
@@ -211,7 +206,7 @@ jobs.
 ### Shared responsibility
-Before the adoption of the CD, the development team could not track what happened to the code
+Before the adoption of CD, the development team could not track what happened to the code
 after its delivery, since government technicians were the only responsibles
 for deploying the project. The implementation of the referred
 approach influenced developers on taking ownership of the project because it
@@ -255,7 +250,7 @@ validated functionalities and sent feedback to developers, patches were
 developed and new versions were packaged and deployed to the VE quickly,
 steadily, and reliably. The constant monitoring of the development work brought
 greater security to the governmental nucleus and improved the interactions of
-this with the team of developers.
+this with our development team.
 ## Challenges