Fix pipeline

Rodrigo Siqueira de Melo
1 parent 6cc43c1e
Showing 1 changed file with 37 additions and 36 deletions Show diff stats
ieeeSW/releaseEng3/IEEE_ThemeIssue_ReleaseEng_CD.md
@@ -96,7 +96,7 @@ worst political crisis after the re-democratization in Brazil.
 ![Deployment Pipeline](figures/pipeCD.png)
-The Figure 1 represents our CD pipeline. The pipeline started when new code arrived.
+Figure 1 represents our CD pipeline. The pipeline started when new code arrived.
 As it went through each step, it was tested and improved until it finally reached
 the production environment. At this point we got back to the first stage to release
 more new code.
@@ -105,26 +105,26 @@ more new code.
 Each one of the Portal's software components had their own test suite. The
 development teams were required to maintain and expand them if possible. The
-communication of all these software was based on a plugin architecture. Testing
-the plugins were our integration tests. Finally, all tests ran in each
-component continuous integration environment.
+communication of all these software is orchestrated by Colab, which is based on
+a plugin architecture. Every component integrated into the Portal had a
+specific plugin developed by us. For instance, we developed integration
+plugins for Gitlab and Mailman. Plugins had their own test suite that
+served as integration tests.
-This two-level testing provided us with the necessary speed and trust that
-guaranteed both component and platform stability. If any error was found, the
-pipeline stopped and the developers were notified. Only after all tests passed
-we moved to preparing the release.
+Both the unit and integration tests provided us the necessary speed and trust
+that guaranteed both component and platform stability. If any test suite failed,
+either by a test error or coverage reduction below a certain threshold, the
+pipeline stopped. Only after all tests passed we moved to prepare the release.
 ### Preparing a new release
-Our release process was divided in two perspectives in terms of Git tags: the
-application and the SPB Portal. The application tag referred to the specific
-feature or bug fix and was a monotonically increasing. A new tag on any system
-yielded a new SPB Portal tag.
-
-When all tests passed for a given component, we manually created a new
-application tag for it. As a consequence, that automatically created a new tag
-for the SPB Portal. Notice that we forked the original software projects
-and, as consequence, we had different tag values.
+A SPB Portal release was composed of all its software components releases. Each
+software component release was a git tag that referred to a specific feature or
+bug fix. When all tests passed for a given component, we manually created a new
+tag for it. Therefore, a new tag on any software component yielded a new SPB
+Portal release. More precisely, SPB had a script that produced a single release
+for the entire system based on each component tag. At the end of this process,
+we started packaging.
 ### Packaging
@@ -133,39 +133,40 @@ packaging a software for that distribution has three steps: write the script
 for the specific environment (RPM), build the package, and upload it to a
 package repository.
-We chose to create our own packages for each software component for several
+We chose to create our own packages for each software component for five
 reasons:
 * Not all software was packaged by the community and those that existed were
 outdated;
 * Packaging makes it easy to manage the software on a given distribution;
-* It simplifies the deployment;
+* Packaging simplifies the deployment;
 * Packaging follows the distribution's best practices and,
-* Allows configurations and permissions control.
+* Packaging allows configurations and permissions control.
-After creating a new tag for one component, the DevOps team was notified and
-the packaging process began. The three packaging steps aforementioned were fully
-automated by a set of scripts. With all these scripts running successfully,
-the new packages would be ready to be used by our subsequent deployment scripts.
+After creating a new tag for one component, the developers informed the
+DevOps [3] team and the packaging process began. The three packaging steps
+aforementioned were fully automated by a set of scripts. With all these scripts
+running successfully, the new packages would be ready to be used by our
+subsequent deployment scripts.
 ### Validation Environment Deployment
 The Validation Environment (VE) is a replica of the Production Environment
-(PE), with two exceptions: only the government officers and us had access to it
-and all the data is anonymised. To configure the environment, we used
-our configuration management tool: Chake (serverless configuration with Chef).
-That maintained environment consistency simplifying the deployment process.
-Additionally, the packages we built on the last step were readily available to be
-used by the management tool.
-
-The VE was used by the government agents to validate new features and required
+(PE), with two exceptions: only the government officers and project leaders had
+access to it and all the data was anonymised. To configure the environment, we
+used a configuration management tool named Chef with Chake support (serverless
+configuration for Chef). That tool maintained environment consistency
+simplifying the deployment process.  Additionally, the packages we built on the
+last step were readily available to be used by the management tool.
+
+Government agents used the VE to validate new features and required
 changes. Also, the VE was useful to verify the integrity of the entire portal
 as part of the next step in the pipeline.
 ### Acceptance Tests
 After we deployed a new SPB Portal version in the VE, the government
-agents are responsible for checking features and bug fixes required by them. If
+agents were responsible for checking features and bug fixes required by them. If
 the requirement analysts identified a problem, they notified the developers via
 comments on the SPB Portal's issue tracker. The problems were fixed and the
 pipeline restarted from scratch. If everything was validated, we moved forward.
@@ -173,7 +174,7 @@ pipeline restarted from scratch. If everything was validated, we moved forward.
 ### Production Environment Deployment
 After the government finished the VE check and it was cleared for deployment,
-we could finally begin the deployment to Production Environment (PE). For this
+we could finally begin the deployment to the Production Environment (PE). For this
 we also used our configuration management tool, the same scripts and package
 versions as in the VE. After the deploy was completed, both VE and PE
 were running identical software. This was the point where new features and bug
@@ -297,6 +298,6 @@ between industry and government, specially regarding CD.
 ## References
 1. G. Booch, A. W. Brown, "Collaborative Development Environments", in Advances in Computers, vol. 59, 2003, pp. 1–27.
-1. L. Chen, "Continuous Delivery: Huge Benefits, but Challenges Too", in IEEE Software, vol. 32, no. 2, 2015, pp. 50-54.
-
+2. L. Chen, "Continuous Delivery: Huge Benefits, but Challenges Too", in IEEE Software, vol. 32, no. 2, 2015, pp. 50-54.
+3. Davis, Jennifer and Daniels, Katherine, Effective DevOps: building a culture of collaboration, affinity, and tooling at scale, 2016, " O'Reilly Media, Inc."