From 1f3dd187813bc80db822cafea91a7021cd5cfcb1 Mon Sep 17 00:00:00 2001 From: Melissa Wen Date: Sat, 18 Nov 2017 10:45:37 -0200 Subject: [PATCH] [i3eSW] Discard suggestion --- ieeeSW/releaseEng3/IEEE_ThemeIssue_ReleaseEng_CD.md | 33 ++++++++++++++++----------------- 1 file changed, 16 insertions(+), 17 deletions(-) diff --git a/ieeeSW/releaseEng3/IEEE_ThemeIssue_ReleaseEng_CD.md b/ieeeSW/releaseEng3/IEEE_ThemeIssue_ReleaseEng_CD.md index fee5982..2de5d55 100644 --- a/ieeeSW/releaseEng3/IEEE_ThemeIssue_ReleaseEng_CD.md +++ b/ieeeSW/releaseEng3/IEEE_ThemeIssue_ReleaseEng_CD.md @@ -160,9 +160,8 @@ the pipeline to release new versions. 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 plugins also have their own test suites and these suites assume a double role -as both plugin tests and as integration tests. These tests provided us the -performance and security needed to guarantee the stability of components and -the platform. If any test suite failed, by either a test error or coverage +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. @@ -170,7 +169,7 @@ passed, the pipeline proceeded to the step of release preparation. 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 -fix. SPB, as an integration project, had its own Git repository +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 passed all of the SPB integration tests, we manually created a corresponding @@ -183,9 +182,8 @@ packaging. Our packaging software approach involves three steps: writing the script for the specific environment, building the package, and uploading it to a package repository. We decided to create separate packages for each system. Packaging -makes it easy to manage software in a given distribution, simplifies -deployment, follows the distribution's best practices, and enables -configuration and permission control. +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 @@ -226,12 +224,14 @@ fixes were finally available to end users. Research points out many CD advantages in the industry [2, 5], such as accelerated time to market, building the right product, productivity and efficiency improvements, stable releases, and better customer satisfaction. + + Working with the government, we noticed the following additional benefits. ### Strengthening Trust in the Relationship with the Government CD helped strengthen trust in the relationship between developers and -the Ministry staff. Before using CD, they had access to the features +the Ministry staff. Before using CD, they could validate features developed only at the end of the release cycle, usually every four months. With the implementation of CD, intermediate and candidate versions became available, allowing them to perform small validations over time. @@ -240,18 +240,17 @@ Ministry leaders and improved the interactions with our team. ### Responsiveness to Change -Responsiveness was one of the direct benefits of adopting the CD pipeline. The +Responsiveness was one of the direct benefits of adopting the CD pipeline. +Political interests may change requirements and priorities at any time. The ability to react quickly to changes requested by the Ministry was vital to the -project’s survival for 30 months. These changes in requirements and priorities -were mostly motivated by political interests. We noticed that if we took too +project’s survival for 30 months. We noticed that if we took too 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 -concerns about the final delivery of the platform. -For our team, CD made developers more -confident that the project would last a little longer. +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 @@ -274,9 +273,9 @@ 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. This problem was -softened when they realized the impact of these delays on the final product and -decided to allocate revisions in their work schedule. +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 +productivity.