[i3eSW] Discard suggestion

Melissa Wen
1 parent 31e674b9
Showing 1 changed file with 16 additions and 17 deletions Show diff stats
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.
 <!---
 Fabio sugeriu Lessons Learned, mas vamos mostrar exemplos da revista para ele olhar.