Merge branch 'ieee_new' of http://softwarepublico.gov.br/gitlab/softwarepublico/…

…articles into ieee_new

Merge branch 'ieee_new' of http://softwarepublico.gov.br/gitlab/softwarepublico/…
…articles into ieee_new
Melissa Wen
2 parents 0371b378 354d2f82
Showing 1 changed file with 45 additions and 47 deletions Show diff stats
ieeeSW/releaseEng3/IEEE_ThemeIssue_ReleaseEng_CD.md
@@ -41,10 +41,10 @@ him at fabio.kon@ime.usp.br.
 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
+technique. This article presents how and why we applied CD in a large Brazilian
 government project for the development of a Collaborative Development
 Environment (CDE), sharing the challenges we faced and the strategies used to
-overcome them.
+overcome them. ( >> FECHAR COM FRASE DE IMPACTO <<<).
 ## Introduction
@@ -69,7 +69,7 @@ team. CD enabled us to show our progress and to earn 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].
+benefits [2,3].
 ## Context
@@ -81,7 +81,7 @@ them unfamiliar with new software development techniques, such as CD. Any of
 our requests had to pass through layers of bureaucracy before being answered;
 accessing their infrastructure to deploy updated software was not different.
 The difficulties were aggravated because the new SPB portal is an unprecedented
-platform in the Brazilian government, with a complicated deployment process.
+platform in the Brazilian government, with a complicated deployment process [4].
 The project suffered significant interference from the board of directors
 throughout time because the portal represents an interface between government
@@ -100,15 +100,16 @@ the widespread belief among government staff that any project in partnership
 with a University is doomed to fail, and (2) dealing with bureaucracies
 involved in the Ministry deployment process.
-Firstly, our team was not from a typical company, consisting mainly of
-undergraduate students supported senior developers and designers, all
-coordinated by two professors. Accordingly, time and resources allocation,
-accountability, and team continuity might be construed as "unprofessional". On
-the government side, the SPB portal evolution was the first software
-development collaboration between universities and the Ministry staff involved,
+First, our development team was not from a typical company, consisting mainly
+of undergraduate interns supported by senior developers and designers, all
+coordinated by two professors. Our unconventional team structure and
+organization might be considered as "unprofessional" by Ministry standards with
+regard to  time and resource allocation, accountability, and team continuity .
+On the government side, the SPB portal evolution was the first software
+development collaboration involving universities and the Ministry staff,
 raising disbelief.
-Secondly, our team approached software deployment differently from the
+Second, our team approached software deployment differently from the
 Ministry. We believed frequent delivery is better for the project’s success.
 In contrast, the Ministry is used to the idea of a single deployment at the end
 of the project, and neither their bureaucratic structure nor their technical
@@ -116,17 +117,17 @@ expertise was conducive to this style of work. That ended up hampering the
 benefits of the tool and preventing us from showing off the fruits of the
 project to those responsible for evaluating it.
-<!-- Melissa: tentar dividir esse último parágrafo em 2? Tá cansativo ler ele todo - não consigo respirar :P -->
+<!-- AHA Moment!!!!!      -->
 These challenges made our relationship with the Ministry staff tense, in
 particular during the first year, and alerted us to the fact that they could
-finish the project at any time. The deployment limitation was the substantial
+cancel the project at any time. The deployment limitation was the substantial
 technical issue we could tackle in the short term. As a result, we worked to
 deploy one version of the project onto our infrastructure and showed it to the
 government evaluators. This strategy proved them we could efficiently provide
 new features, fulfill their expectations regarding the delivery of the
 requirements, and incited them to demand that the latest version be deployed in
-the Ministry infrastructure. This generated more pressure on the IT
+the Ministry infrastructure. Our CD approach generated more pressure on the IT
 department responsible for the deployment routines. With each CD cycle, we
 gradually built a new relationship among all parties and, by the end of the
 project, we became active participants in the deploy operations.
@@ -134,33 +135,33 @@ project, we became active participants in the deploy operations.
 ## Our Continuous Delivery Pipeline
 SPB portal is a CDE with additional social features, having 83 software
-communities and 6,460 users. We built system-of-systems adapting and
-integrating five existing OSS projects: Colab (www.github.com/colab), Noosfero
-(www.noosfero.org), Gitlab (www.gitlab.com), Mezuro (www.mezuro.org), and
-Mailman (www.list.org). Colab orchestrates these multiple components and
-allowed us to smoothly provide a unified interface for final users, including
-single sign-on and global searches [1]. All these integrated systems represents
-a total of 106.253 commits and 1.347.421 lines of code.
+communities and 6,460 users, mostly government employees. We built
+system-of-systems adapting and integrating five existing OSS projects: Colab
+(www.github.com/colab), Noosfero (www.noosfero.org), Gitlab (www.gitlab.com),
+Mezuro (www.mezuro.org), and
+Mailman (www.list.org). Colab orchestrates these multiple systems using a
+plugin architecture and allows us to smoothly provide a unified interface for
+final users, including single sign-on and global searches [1]. All these
+integrated systems represents a total of 106.253 commits and 1.347.421 lines of
+code.
 ![The SPB Deployment Pipeline.](figures/pipeline.png)
-The portal deployment follows a typical CD pipeline [3], adapted to the
+The portal deployment follows a typical CD pipeline [5], adapted to the
 technical and organizational context of our project and the use of OSS best
 practices, as presented in Figure 1. It started when new code arrived; and when
 it reaches the production environment, we would restart the pipeline to release
 new versions.
-<!-- Fabio: Neste ponto eu já gostaria de ter uma ideia do tamanho do sistema [..] eu gostaria de ter outros números como linhas de código [x], quantidade de componentes[x], usuários desenvolvedores esperados[Temos acesso?], etc. [atualmente, 83 softwares abrigado no portal?]-->
-
 ### Automated Tests
-Each integrated system had to be tested with its own test suite. This checking
-was not enough, however: we even had to test the platform as a whole. Given
-that the plugins also have their own test suites and these suites assume a
-double role as both plugin tests and as integration tests. If any test suite
-failed, by either a test error or coverage reduction below a certain threshold,
-the process stopped. Only when all tests passed, the pipeline proceeded to the
-step of release preparation.
+In practice, each integrated system is a Colab plugin and had to be tested with
+its own test suite. However, this checking was not enough: we also had to test
+the platform as a whole. Since the plugins have their own test suites, they
+also assume a double role as both plugin tests and as integration tests. If any
+test suite failed, by either a test error or coverage reduction below a certain
+threshold, the process stopped. Only when all tests passed, the pipeline
+proceeded to the step of release preparation.
 ### Preparing a New Release
@@ -213,7 +214,7 @@ point, new features and bug fixes were finally available to end users.
 CD brings many advantages such as accelerated time to market, building the
 right product, productivity and efficiency improvements, stable releases, and
-better customer satisfaction [2]. The charts presented in Figure 2 show these
+better customer satisfaction [2,3]. The charts presented in Figure 2 show these
 benefits of CD in our project and associates them with the creation of a DevOps
 team. In the time of 30 months, we deployed a total of 84 versions. Over 64% of
 these activities happened in the second half of 2015, with the DevOps team
@@ -252,7 +253,7 @@ According to the conventional Ministry process, the development team could not
 track what happened to the code after its delivery, since their staff was the
 only ones responsible for deployment. The implementation of CD made our
 development team feel equally responsible for what was getting into production
-and take ownership of the project.
+and take ownership of the project [4].
 Interestingly, the CD pipeline had the same effect on the Ministry staff. They
 became more engaged in the whole process, opening and discussing issues during
@@ -277,6 +278,9 @@ Fabio sugeriu Lessons Learned, mas vamos mostrar exemplos da revista para ele ol
 ## Lessons Learned
+<!---
+(>>>FABIO FAZER RELAÇÃO COM CHALLENGES DA SEÇÃO CONTEXTO<<<).
+-->
 Due to the successful building of the CD pipeline, we improved the Ministry
 deployment process and kept the project alive. We now look at the lessons
 learned.
@@ -289,7 +293,7 @@ available to build the pipeline. The construction and maintenance of the CD
 process were made possible by the key decisions to:
 1. _Select the most experienced senior developers and some advanced students of
-the project to work on a specific DevOps team._These senior developers used
+the project to work on a specific DevOps team._ These senior developers used
 their experience in OSS projects to craft an initial proposal for the
 deployment process. The solution enabled us to automate the deployment, even
 though the process was, initially, still rudimentary.
@@ -304,7 +308,7 @@ process on-the-fly.
 Adopting an unfamiliar approach requires trust. Ministry staff, traditionally,
 expected and were prepared to validate and deploy a single deliverable. However,
 the steady growth of SPB complexity made large deliveries unsustainable. The CD
-approach was necessary. Therefore, we developed the following line of action to
+approach was necessary [4]. Therefore, we developed the following line of action to
 make this new dynamics possible:
 1. _Demonstrate actual results, do not simply tell._ Initially, we did not have
@@ -333,20 +337,14 @@ both VE and PE.
 ## References
-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.
-1. L. Chen, "Continuous Delivery: Huge Benefits, but Challenges Too", IEEE Software, vol. 32, no. 2, 2015, pp. 50-54.
-1. J. Humble and D. Farley, "Continuous Delivery: Reliable Software Releases Through Build, Test, and Deployment Automation", Addison-Wesley Professional, 2010.
+1. P. Meirelles, M. Wen, A. Terceiro, R. Siqueira, L. Kanashiro, and H. Neri, "Brazilian Public Software Portal: an integrated platform for collaborative development", OpenSym, 2017. 
+1. L. Chen, "Continuous Delivery: Huge Benefits, but Challenges Too", IEEE Software, 32 (2) 2015.
+1. T. Savor, M. Douglas, M. Gentili, L. Williams, K. Beck and M. Stumm, "Continuous Deployment at Facebook and OANDA", ICSE, 2016.
+1. M. Shahin, M. A. Babar, and L. Zhu. “The Intersection of Continuous Deployment and Architecting Process: Practitioners' Perspectives”. ESEM, 2016.
+1. J. Humble and D. Farley, "Continuous Delivery: Reliable Software Releases Through Build, Test, and Deployment Automation", Addison-Wesley, 2010.
 <!---
-Citadas apenas para definir coisas já disseminadas
-1. G. Booch and A. Brown, A. W. "Collaborative Development Environments", Advances in Computers, vol. 59, 2003, pp. 1-27.
 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.
-1. J. Davis and K. Daniels, "Effective Devops: Building a Culture of Collaboration, Affinity, and Tooling at Scale", O'Reilly Media, Inc., 2016.
+-->
-Estava citada apenas na introdução dos benefícios
-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.
-Considerar:
-2017 State of DevOps Report
-https://puppet.com/resources/whitepaper/state-of-devops-report
--->