diff --git a/ieeeSW/releaseEng3/IEEE_ThemeIssue_ReleaseEng_CD.md b/ieeeSW/releaseEng3/IEEE_ThemeIssue_ReleaseEng_CD.md index 48aa31e..7224c46 100644 --- a/ieeeSW/releaseEng3/IEEE_ThemeIssue_ReleaseEng_CD.md +++ b/ieeeSW/releaseEng3/IEEE_ThemeIssue_ReleaseEng_CD.md @@ -101,7 +101,7 @@ involved in the 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 +as "unprofessional." On the government side, the SPB portal evolution was the first software development collaboration between universities and the Ministry staff involved, raising disbelief. @@ -109,7 +109,7 @@ Secondly, 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 expertise -were conductive with this style of work. That ended up hampering the benefits of +were conducive with 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. @@ -123,7 +123,7 @@ 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 the latest version to be deployed in -the Ministry infrastructure. This generated more pressure on the IT department +the Ministry infrastructure. This efficiency 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. @@ -137,12 +137,12 @@ team shrinked to 20 students, one designer, and two developers. --> ## Our Continuous Delivery Pipeline -SPB portal was designed as a CDE with additional social features. We build +SPB portal is a CDE with additional social features. 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). All integrated system represents a total of more than 106.253 commits and 1.347.421 lines of code. -That solution orchestrates these multiple components and allowed us to smoothly +That solution orchestrated these multiple components and allowed us to smoothly provide a unified interface for final users, including single sign-on and global searches [1]. @@ -154,8 +154,8 @@ practices, as presented in Figure 1. ### Automated Tests -Each integrated system had to be tested with its own test suite. This was not -enough, however: we also had to test the platform as a whole. Given that the +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 @@ -165,10 +165,10 @@ passed, the pipeline proceeded to the step of release preparation. ### Preparing a New Release Each software component was hosted in a separate Git repository. A new release -of a component was tagged with a reference to a specific new feature or bug +of a component was tagged referencing a specific new feature or bug fix. SPB had its own Git repository -(www.softwarepublico.gov.br/gitlab/softwarepublico). A SPB portal release was -an aggregate of releases of all of its components. When a new component release +(www.softwarepublico.gov.br/gitlab/softwarepublico). An SPB portal release was +an aggregate of versions of all of its components. When a new component release passed all of the SPB integration tests, we manually created a corresponding new tag in its repository. Therefore, a new tag on any software component yielded a new SPB portal release. At the end of this process, we started @@ -183,7 +183,7 @@ brings portability, simplifies deployment, and enables configuration and permission control. After creating a new tag for a system, the developers informed our DevOps [4] -team and the packaging process began. A set of scripts fully automated the +team, and the packaging process began. A set of scripts fully automated the three packaging steps aforementioned. When all of them ran successfully, the new packages would be ready and available for our deployment scripts. @@ -193,7 +193,7 @@ The Validation Environment (VE) is a replica of the Production Environment (PE) with anonymised data, and access restricted to Ministry staff and our DevOps team. To configure this environment, we used Chef (www.chef.io) and Chake, a serverless configuration tool created by our team -(www.github.com/terceiro/chake). This maintained environment consistency, +(www.github.com/terceiro/chake). This tool maintained environment consistency, simplifying the deployment process. The Ministry staff used the VE to validate new features and required changes. @@ -202,7 +202,7 @@ the next step in the pipeline. ### Acceptance Tests -After a new SPB portal deployment in the VE, the Ministry were +After a new SPB portal deployment in the VE, the Ministry was responsible for checking the required features and bug fixes. If they identified a problem, they would notify the developers via comments on the SPB portal's issue tracker, prompting the team to fix @@ -227,8 +227,7 @@ project and associates them with the creation of a DevOps team. ![The evolution of SPB releases and the team members distribution in the period.](figures/CDReleaseAndTeamEvolution.png) 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, when the DevOps team was -created. Even with the reduction of the team as a whole, in the last months of +activities happened in the second half of 2015, with the DevOps team creation. Even with the reduction of the team as a whole, in the last months of the project, this pace of deployment was maintained until we finished all our activities. @@ -255,14 +254,14 @@ long to meet their demands, they would threaten to reduce financial support and even cancel the project. CD helped us keep the PE up-to-date, even with partial versions of a feature. -Therefore, we always had something to show on meetings, easying their +Therefore, we always had something to show on meetings, easing their concerns about the final delivery of the platform. For our team, CD made developers more confident that the project would last a little longer. ### Shared Responsibility According to the conventional Ministry process, the development team could not -track what happened to the code after its delivery, since their staff were +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. @@ -280,8 +279,8 @@ development team and the Ministry staff: each party had to be prepared to take action as soon as the other concluded a given task. Initially, the Ministry staff did not contemplate this in their schedule which, combined with the bureaucracy in providing access to the PE (up to 3 days), resulted in -significant delays in the validation of new features. The clear use of CD -pipeline helped us to identify and solve key points of delay, and increase our +significant delays in the validation of new features. The use of an explicit CD +pipeline helped us to identify critical points of delay, and increase our productivity. Taking on the responsibility for implementing CD impacted the whole team. Most -of our team members did not have CD know-how and we had few working hours +of our team members did not have CD know-how, and we had few working hours available to build the pipeline. The construction and maintenance of the CD process were made possible by the key decisions to: @@ -327,8 +326,8 @@ evolving the process on-the-fly. Adopting an unfamiliar approach requires trust. In the Ministry, traditionally, -software was the product delivered at the end of a development contract; they -expected and were prepared to validate and deploy a single deliverable. This +a software was the product delivered at the end of a development contract; they +expected and were prepared to validate and deploy a single deliverable. This process was not adequate for the SPB: because the SPB portal is a system-of-systems, the steady growth of its complexity made large deliveries unsustainable. Therefore, the CD approach was necessary, but how @@ -344,8 +343,8 @@ production by the Ministry staff. Second, specific issues of the Ministry infrastructure made some validated features not work as expected in the PE. That situation gave us arguments to negotiate access to the PE. -2. _Make project management transparent and collaborative for government -staff._ Allowing the Ministry staff to track our development process showed them +2. _Make project management transparent and collaborative for government staff._ +Allowing the Ministry staff to track our development process showed them we were fulfilling our commitments. They started to interact more actively in the generation of versions and became involved in the CD. After understanding it, the Ministry staff helped us negotiate access to a VE with the Ministry leaders, @@ -357,7 +356,7 @@ involved in the process. They saw the mobilization and responsiveness of our team to generate each new version package. They also recognized the quality of our work and deployment process. In the end, the Ministry staff realized that it would be beneficial for the project if they granted us access to the -infrastructure, both VE and PE. +infrastructure, both VE, and PE. ## References -- libgit2 0.21.2