From 354d2f823555479c7b6d6543e2571f0c1b02f035 Mon Sep 17 00:00:00 2001 From: rodrigosiqueira Date: Mon, 20 Nov 2017 12:18:00 -0200 Subject: [PATCH] Versão pós hangout --- ieeeSW/releaseEng3/IEEE_ThemeIssue_ReleaseEng_CD.md | 92 +++++++++++++++++++++++++++++++++++++++++++++----------------------------------------------- 1 file changed, 45 insertions(+), 47 deletions(-) diff --git a/ieeeSW/releaseEng3/IEEE_ThemeIssue_ReleaseEng_CD.md b/ieeeSW/releaseEng3/IEEE_ThemeIssue_ReleaseEng_CD.md index 910dc06..b83b0c2 100644 --- a/ieeeSW/releaseEng3/IEEE_ThemeIssue_ReleaseEng_CD.md +++ b/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. - + 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. - - ### 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 + 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. -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 ---> -- libgit2 0.21.2