From 6f79d27de1360e1fd817b216f684c33ed96881bf Mon Sep 17 00:00:00 2001 From: Paulo Meirelles Date: Sat, 11 Nov 2017 01:20:51 -0200 Subject: [PATCH] Merging original and new context section --- ieeeSW/releaseEng3/IEEE_ThemeIssue_ReleaseEng_CD.md | 132 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++----------------------------------------------------------- 1 file changed, 73 insertions(+), 59 deletions(-) diff --git a/ieeeSW/releaseEng3/IEEE_ThemeIssue_ReleaseEng_CD.md b/ieeeSW/releaseEng3/IEEE_ThemeIssue_ReleaseEng_CD.md index fb1487e..0d019d3 100644 --- a/ieeeSW/releaseEng3/IEEE_ThemeIssue_ReleaseEng_CD.md +++ b/ieeeSW/releaseEng3/IEEE_ThemeIssue_ReleaseEng_CD.md @@ -1,3 +1,8 @@ + --- title: "Title: Continuous Delivery: a tool to build trust in a large-scale, complex Government organization" papersize: a4 @@ -29,71 +34,80 @@ __Fabio Kon__ ... 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. ## Introduction + -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. +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. 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]. ## Context + + +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. + + + +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. + + + +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. + + + + + +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. + +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. + + + +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. + + + +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. + + -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. - -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. - ---- To be continued --- - -To achieve the SPB project goals, we had to overcome strong political bias tied -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 -(such as social and collaboration network, Git repository manager, mailing -list, source code metric evaluation, and a systems integration platform) 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 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: to transfer knowledge to undergraduate -students and to deal with 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 focused on -automating the deploy process; for instance, one of our senior developers -created a tool called Chake (www.gitlab.com/terceiro/chake) to help us manage -multiple hosts without the need for a Chef-Server (www.chef.io/chef). 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. 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. +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. ## Our Continuous Delivery Pipeline -- libgit2 0.21.2