[i3eSW] Grammarly Pipeline

Melissa Wen
1 parent 86bc0133
Showing 1 changed file with 37 additions and 40 deletions Show diff stats
ieeeSW/releaseEng3/IEEE_ThemeIssue_ReleaseEng_CD.md
@@ -130,22 +130,21 @@ e está bem colocada. Se decidirmos tirar, teremos que repensar o parágrafo.
 -->
 The SPB portal is a system-of-systems with several integrated software projects.
 Each of them, as well as the entire platform, had to be tested. These software
-components have their own test suite. Communication between all components is
-orchestrated by Colab, a systems integration platform for web applications based
-on a plugins architecture. Therefore, specific plugins were developed for
-each portal software component, such as Gitlab (www.gitlab.com) and
-Noosfero (www.noosfero.org). Each plugin has its own test suite and this set
-also worked as integration tests.
+components have own test suite. Colab, a systems integration platform for web
+applications based on a plugins architecture, orchestrate communication between
+all of them. Therefore, we developed specific plugins for each portal software
+component, such as Gitlab (www.gitlab.com) and Noosfero (www.noosfero.org). Each
+plugin also has own test suite, and this set also worked as integration tests.
  
 Both unit and integration tests provided us the performance and security needed
-to guarantee the stability for components and the platform. If any test suite
+to guarantee the stability of components and the platform. If any test suite
 failed, by either a test error or coverage reduction below a certain threshold,
-the pipeline stopped. Only when all tests passed, the pipeline proceeded to the
+the process stopped. Only when all tests passed, the pipeline proceeded to the
 step of preparing the release.
  
 ### Preparing a New Release
  
-A SPB Portal release was composed of all its software components releases. Each
+An 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
@@ -155,57 +154,55 @@ we started packaging.
  
 ### 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.  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 decided to create our own packages for each software component for the following five
-reasons:
+We decided to create own packages for each software component for the following
+five 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;
 * Packaging simplifies the deployment;
 * Packaging follows the distribution's best practices and,
 * Packaging allows configurations and permissions control.
  
-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.
+After creating a new tag for one component, the developers informed the DevOps
+[3] team, and the packaging process began. A set of scripts fully automated the
+three packaging steps aforementioned. With all them running successfully, the
+new packages would be ready to be used by our 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 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.
+The Validation Environment (VE) is a replica of the Production Environment (PE),
+with two exceptions: only the government officers and project leaders had access
+to it and all the data became anonymous. To configure the environment, we used a
+configuration management tool named Chef with Chake support (serverless
+configuration for Chef). It 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.
+Government agents used the VE to validate new features and required changes. Also,
+the VE was used 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 were responsible for checking features and bug fixes required by them. If
 the requirement analysts identified a problem, they would notify 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.
+comments on the SPB Portal's issue tracker. The development team fixed the problem
+and the 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 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
-fixes were finally available to the end users.
+When the government finished the VE check, we could finally begin the deployment
+in 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. Here was
+the point where new features and bug fixes were finally available to the end
+users.
  
 ## Benefits
...	...	@@ -130,22 +130,21 @@ e está bem colocada. Se decidirmos tirar, teremos que repensar o parágrafo.
130	130	-->
131	131	The SPB portal is a system-of-systems with several integrated software projects.
132	132	Each of them, as well as the entire platform, had to be tested. These software
133		-components have their own test suite. Communication between all components is
134		-orchestrated by Colab, a systems integration platform for web applications based
135		-on a plugins architecture. Therefore, specific plugins were developed for
136		-each portal software component, such as Gitlab (www.gitlab.com) and
137		-Noosfero (www.noosfero.org). Each plugin has its own test suite and this set
138		-also worked as integration tests.
	133	+components have own test suite. Colab, a systems integration platform for web
	134	+applications based on a plugins architecture, orchestrate communication between
	135	+all of them. Therefore, we developed specific plugins for each portal software
	136	+component, such as Gitlab (www.gitlab.com) and Noosfero (www.noosfero.org). Each
	137	+plugin also has own test suite, and this set also worked as integration tests.
139	138
140	139	Both unit and integration tests provided us the performance and security needed
141		-to guarantee the stability for components and the platform. If any test suite
	140	+to guarantee the stability of components and the platform. If any test suite
142	141	failed, by either a test error or coverage reduction below a certain threshold,
143		-the pipeline stopped. Only when all tests passed, the pipeline proceeded to the
	142	+the process stopped. Only when all tests passed, the pipeline proceeded to the
144	143	step of preparing the release.
145	144
146	145	### Preparing a New Release
147	146
148		-A SPB Portal release was composed of all its software components releases. Each
	147	+An SPB Portal release was composed of all its software components releases. Each
149	148	software component release was a git tag that referred to a specific feature or
150	149	bug fix. When all tests passed for a given component, we manually created a new
151	150	tag for it. Therefore, a new tag on any software component yielded a new SPB
...	...	@@ -155,57 +154,55 @@ we started packaging.
155	154
156	155	### Packaging
157	156
158		-The platform is running on the CentOS 7 GNU/Linux distribution. Basically,
159		-packaging a software for that distribution has three steps: write the script
160		-for the specific environment (RPM), build the package, and upload it to a
161		-package repository.
	157	+The platform is running on the CentOS 7 GNU/Linux distribution. Packaging a
	158	+software for that distribution has three steps: write the script for the
	159	+specific environment (RPM), build the package, and upload it to a package
	160	+repository.
162	161
163		-We decided to create our own packages for each software component for the following five
164		-reasons:
	162	+We decided to create own packages for each software component for the following
	163	+five reasons:
165	164
166		-* Not all software was packaged by the community and those that existed were
167		-outdated;
	165	+* Not all software was packaged by the community and those that existed were outdated;
168	166	* Packaging makes it easy to manage the software on a given distribution;
169	167	* Packaging simplifies the deployment;
170	168	* Packaging follows the distribution's best practices and,
171	169	* Packaging allows configurations and permissions control.
172	170
173		-After creating a new tag for one component, the developers informed the
174		-DevOps [3] team and the packaging process began. The three packaging steps
175		-aforementioned were fully automated by a set of scripts. With all these scripts
176		-running successfully, the new packages would be ready to be used by our
177		-subsequent deployment scripts.
	171	+After creating a new tag for one component, the developers informed the DevOps
	172	+[3] team, and the packaging process began. A set of scripts fully automated the
	173	+three packaging steps aforementioned. With all them running successfully, the
	174	+new packages would be ready to be used by our deployment scripts.
178	175
179	176	### Validation Environment Deployment
180	177
181		-The Validation Environment (VE) is a replica of the Production Environment
182		-(PE), with two exceptions: only the government officers and project leaders had
183		-access to it and all the data was anonymised. To configure the environment, we
184		-used a configuration management tool named Chef with Chake support (serverless
185		-configuration for Chef). That tool maintained environment consistency
186		-simplifying the deployment process. Additionally, the packages we built on the
187		-last step were readily available to be used by the management tool.
	178	+The Validation Environment (VE) is a replica of the Production Environment (PE),
	179	+with two exceptions: only the government officers and project leaders had access
	180	+to it and all the data became anonymous. To configure the environment, we used a
	181	+configuration management tool named Chef with Chake support (serverless
	182	+configuration for Chef). It maintained environment consistency simplifying the
	183	+deployment process. Additionally, the packages we built on the last step were
	184	+readily available to be used by the management tool.
188	185
189		-Government agents used the VE to validate new features and required
190		-changes. Also, the VE was useful to verify the integrity of the entire portal
191		-as part of the next step in the pipeline.
	186	+Government agents used the VE to validate new features and required changes. Also,
	187	+the VE was used to verify the integrity of the entire portal as part of the next
	188	+step in the pipeline.
192	189
193	190	### Acceptance Tests
194	191
195	192	After we deployed a new SPB Portal version in the VE, the government
196	193	agents were responsible for checking features and bug fixes required by them. If
197	194	the requirement analysts identified a problem, they would notify the developers via
198		-comments on the SPB Portal's issue tracker. The problems were fixed and the
199		-pipeline restarted from scratch. If everything was validated, we moved forward.
	195	+comments on the SPB Portal's issue tracker. The development team fixed the problem
	196	+and the pipeline restarted from scratch. If everything was validated, we moved forward.
200	197
201	198	### Production Environment Deployment
202	199
203		-After the government finished the VE check and it was cleared for deployment,
204		-we could finally begin the deployment to the Production Environment (PE). For this
205		-we also used our configuration management tool, the same scripts and package
206		-versions as in the VE. After the deploy was completed, both VE and PE
207		-were running identical software. This was the point where new features and bug
208		-fixes were finally available to the end users.
	200	+When the government finished the VE check, we could finally begin the deployment
	201	+in the Production Environment (PE). For this we also used our configuration
	202	+management tool, the same scripts and package versions as in the VE. After the
	203	+deploy was completed, both VE and PE were running identical software. Here was
	204	+the point where new features and bug fixes were finally available to the end
	205	+users.
209	206
210	207	## Benefits
211	208
...	...