[ieeeSW] Review pipeline

Paulo Meireles
1 parent a4e97ab6
Showing 1 changed file with 35 additions and 40 deletions Show diff stats
ieeeSW/releaseEng3/IEEE_ThemeIssue_ReleaseEng_CD.md
@@ -121,54 +121,48 @@ we moved to preparing the release.
 ### Preparing a new release
-Our release process was divided in two perspectives in terms of git tags: the
+Our release process was divided in two perspectives in terms of Git tags: the
 application and the SPB Portal. The application tag refers to the specific
 feature or bug fix and is 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 have forks of the original softwares and, as
-consequence, we had different tag values.
+for the SPB Portal. Notice that we forked of the original software projects
+and, as consequence, we had different tag values.
 ### Packaging
-The platform is running on the CentOS 7 GNU/Linux distribution.
-Basically, 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.
+The platform is running on the CentOS 7 GNU/Linux distribution.  Basically,
+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
 reasons:
-* Not all software was packaged by the community;
-* And those that existed were outdated;
+
+* 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 follows the distribution’s best practices and,
 * Allows configurations and permissions control.
 After creating a new tag for one component, the DevOps team was notified and
-packaging process began. In the normal case, the three packaging steps
-aforementioned were fully automated by a set of scripts.
-
-However, if the developers reported to DevOps any eventual dependency change,
-the first packaging step had to be manual. For instance, suppose one system
-starts requiring another system to be initialized first. That required the
-DevOps to manually update the packaging script respective to these systems.
-
-After all these scripts have run successfully, the new packages would be ready
-to use by our subsequent deployment scripts.
+the packaging process began. In the normal case, 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 use by our subsequent
+deployment scripts.
-### Validation Environment
-
-[//]: # (TODO - Mencionar que a ferramenta era baseada em Chef - Dá um peso importante.)
+### 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 use a
-configuration management tool. That maintained environment consistency
-simplifying the deployment process. Additionally, the packages we built on
-the last step were readily available to use by the management tool.
+as well as 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
+use by the management tool.
 The VE was used by the government agents to validate new features and required
 changes. Also, the VE was useful to verify the integrity of the entire portal
@@ -176,20 +170,21 @@ as part of the next step in the pipeline.
 ### Acceptance Tests
-After we completely deploy a new SPB Portal version in the VE, the government agents
-are responsible for checking features and/or bug fixes required by them. If the
-technicians identify a problem, they notify the developers. These problems are
-fixed and the pipeline restarts from scratch. If everything is validated, we
-move forward.
-
-### Production Deployment
-
-After the government finish the VE check, it is cleared for deployment and we
-can finally begin the deployment to Production Environment (PE). For this we
-use the same configuration management tool as in the VE as well with same
-scripts and package versions. After the deploy is completed, both VE and PE
-are running identical software. This is the point where new features and bug
-fixes are finally available to end users.
+After we completely deploy, a new SPB Portal version in the VE, the government
+agents are responsible for checking features and bug fixes required by them. If
+the technicians identify a problem, they notified the developers via comments
+on an git issue related to the user story (features) already registered in our
+Gitlab at the SPB Portal. These problems were fixed and the pipeline restarted
+from scratch. If everything is validated, we moved forward.
+
+### Production Environment Deployment
+
+After the government finished the VE check, it was cleared for deployment and
+we could finally began the deployment to Production Environment (PE). For this
+we also used our configuration management tool as in the VE as well with same
+scripts and package versions. After the deploy was completed, both VE and PE
+were running identical software. This was the point where new features and bug
+fixes were finally available to the end users.
 ## Benefits