Merge branch 'master' of http://softwarepublico.gov.br/gitlab/softwarepublico/articles

Melissa Wen
2 parents 0e1df5b3 3dba9c91
Showing 1 changed file with 26 additions and 28 deletions Show diff stats
ieeeSW/releaseEng3/IEEE_ThemeIssue_ReleaseEng_CD.md
@@ -101,10 +101,10 @@ the worst political crisis after the re-democratization in Brazil.
  
 ![Deployment Pipeline](figures/pipeCD.png)
  
-The figure represents our CD pipeline: it starts with new code arriving
-which is tested and improved during as necessary as it goes through each one
-of the steps until finally reaches the production environment. At this point
-we get back to the first stage to release more new code.
+The figure 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.
  
 ### Automated tests
  
@@ -122,13 +122,13 @@ we moved to preparing 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 refers to the specific
-feature or bug fix and is a monotonically increasing. A new tag on any system
+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 of the original software projects
+for the SPB Portal. Notice that we forked the original software projects
 and, as consequence, we had different tag values.
  
 ### Packaging
@@ -145,24 +145,23 @@ reasons:
 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,
+* 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
-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.
+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
-as well as all the data is anonymised. To configure the environment, we used
+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
-use by the management tool.
+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
 changes. Also, the VE was useful to verify the integrity of the entire portal
@@ -170,19 +169,18 @@ 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
+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
-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.
+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.
  
 ### 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
+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 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.
  
@@ -195,8 +193,8 @@ Working with the government, we noticed the following additional benefits.
  
 ### Response to mistrust
  
-The direct benefit from the CD pipeline was the fast response to the changes
-required by the government. That was vital for the project’s renewal over the
+The direct benefit from the CD pipeline was the fast response to changes
+required by the government. That was vital for the project's renewal over the
 years. We could manage the tension between the government and the development
 team better. Every meeting with the government leader was delicate and resulted
 on many new requirements, most of them motivated by political needs. For
@@ -298,10 +296,10 @@ are needed.
  
 ### Overcoming mistrust
  
-In the project’s first half we struggled with deploy related problems in the
+In the project's first half we struggled with deploy related problems in the
 government structure. We were in a paradoxical situation. The government
 demanded speedy deliveries but would not give access to their production
-infrastructure. Afterwards some interactions with government agents, they
+infrastructure. After some interactions with government agents, they
 created the VE as an isolated replica of the PE in their own infrastructure.
 The government agents then realised that it could be beneficial for the project
 if they granted us access to part of the structure.  We believe it is required
...	...	@@ -101,10 +101,10 @@ the worst political crisis after the re-democratization in Brazil.
101	101
102	102	![Deployment Pipeline](figures/pipeCD.png)
103	103
104		-The figure represents our CD pipeline: it starts with new code arriving
105		-which is tested and improved during as necessary as it goes through each one
106		-of the steps until finally reaches the production environment. At this point
107		-we get back to the first stage to release more new code.
	104	+The figure represents our CD pipeline. The pipeline started when new code arrived.
	105	+As it went through each step, it was tested and improved until it finally reached
	106	+the production environment. At this point we got back to the first stage to release
	107	+more new code.
108	108
109	109	### Automated tests
110	110
...	...	@@ -122,13 +122,13 @@ we moved to preparing the release.
122	122	### Preparing a new release
123	123
124	124	Our release process was divided in two perspectives in terms of Git tags: the
125		-application and the SPB Portal. The application tag refers to the specific
126		-feature or bug fix and is a monotonically increasing. A new tag on any system
	125	+application and the SPB Portal. The application tag referred to the specific
	126	+feature or bug fix and was a monotonically increasing. A new tag on any system
127	127	yielded a new SPB Portal tag.
128	128
129	129	When all tests passed for a given component, we manually created a new
130	130	application tag for it. As a consequence, that automatically created a new tag
131		-for the SPB Portal. Notice that we forked of the original software projects
	131	+for the SPB Portal. Notice that we forked the original software projects
132	132	and, as consequence, we had different tag values.
133	133
134	134	### Packaging
...	...	@@ -145,24 +145,23 @@ reasons:
145	145	outdated;
146	146	* Packaging makes it easy to manage the software on a given distribution;
147	147	* It simplifies the deployment;
148		-* Packaging follows the distribution’s best practices and,
	148	+* Packaging follows the distribution's best practices and,
149	149	* Allows configurations and permissions control.
150	150
151	151	After creating a new tag for one component, the DevOps team was notified and
152		-the packaging process began. In the normal case, the three packaging steps
153		-aforementioned were fully automated by a set of scripts. With all these scripts
154		-running successfully, the new packages would be ready to use by our subsequent
155		-deployment scripts.
	152	+the packaging process began. The three packaging steps aforementioned were fully
	153	+automated by a set of scripts. With all these scripts running successfully,
	154	+the new packages would be ready to be used by our subsequent deployment scripts.
156	155
157	156	### Validation Environment Deployment
158	157
159	158	The Validation Environment (VE) is a replica of the Production Environment
160	159	(PE), with two exceptions: only the government officers and us had access to it
161		-as well as all the data is anonymised. To configure the environment, we used
	160	+and all the data is anonymised. To configure the environment, we used
162	161	our configuration management tool: Chake (serverless configuration with Chef).
163	162	That maintained environment consistency simplifying the deployment process.
164		-Additionally, the packages we built on the last step were readily available to
165		-use by the management tool.
	163	+Additionally, the packages we built on the last step were readily available to be
	164	+used by the management tool.
166	165
167	166	The VE was used by the government agents to validate new features and required
168	167	changes. Also, the VE was useful to verify the integrity of the entire portal
...	...	@@ -170,19 +169,18 @@ as part of the next step in the pipeline.
170	169
171	170	### Acceptance Tests
172	171
173		-After we completely deploy, a new SPB Portal version in the VE, the government
	172	+After we deployed a new SPB Portal version in the VE, the government
174	173	agents are responsible for checking features and bug fixes required by them. If
175		-the technicians identify a problem, they notified the developers via comments
176		-on an git issue related to the user story (features) already registered in our
177		-Gitlab at the SPB Portal. These problems were fixed and the pipeline restarted
178		-from scratch. If everything is validated, we moved forward.
	174	+the requirement analysts identified a problem, they notified the developers via
	175	+comments on the SPB Portal's issue tracker. The problems were fixed and the
	176	+pipeline restarted from scratch. If everything was validated, we moved forward.
179	177
180	178	### Production Environment Deployment
181	179
182		-After the government finished the VE check, it was cleared for deployment and
183		-we could finally began the deployment to Production Environment (PE). For this
184		-we also used our configuration management tool as in the VE as well with same
185		-scripts and package versions. After the deploy was completed, both VE and PE
	180	+After the government finished the VE check and it was cleared for deployment,
	181	+we could finally begin the deployment to Production Environment (PE). For this
	182	+we also used our configuration management tool, the same scripts and package
	183	+versions as in the VE. After the deploy was completed, both VE and PE
186	184	were running identical software. This was the point where new features and bug
187	185	fixes were finally available to the end users.
188	186
...	...	@@ -195,8 +193,8 @@ Working with the government, we noticed the following additional benefits.
195	193
196	194	### Response to mistrust
197	195
198		-The direct benefit from the CD pipeline was the fast response to the changes
199		-required by the government. That was vital for the project’s renewal over the
	196	+The direct benefit from the CD pipeline was the fast response to changes
	197	+required by the government. That was vital for the project's renewal over the
200	198	years. We could manage the tension between the government and the development
201	199	team better. Every meeting with the government leader was delicate and resulted
202	200	on many new requirements, most of them motivated by political needs. For
...	...	@@ -298,10 +296,10 @@ are needed.
298	296
299	297	### Overcoming mistrust
300	298
301		-In the project’s first half we struggled with deploy related problems in the
	299	+In the project's first half we struggled with deploy related problems in the
302	300	government structure. We were in a paradoxical situation. The government
303	301	demanded speedy deliveries but would not give access to their production
304		-infrastructure. Afterwards some interactions with government agents, they
	302	+infrastructure. After some interactions with government agents, they
305	303	created the VE as an isolated replica of the PE in their own infrastructure.
306	304	The government agents then realised that it could be beneficial for the project
307	305	if they granted us access to part of the structure. We believe it is required
...	...