[ieeeSW] more improvements and less words

Paulo Meireles
1 parent e732ed58
Showing 1 changed file with 7 additions and 11 deletions Show diff stats
ieeeSW/releaseEng3/IEEE_ThemeIssue_ReleaseEng_CD.md
@@ -130,6 +130,7 @@ project, we became active participants in the deploy operations.
  
 ## Our Continuous Delivery Pipeline
  
+<--! discutir a precisão dos dados -->
 SPB portal is a CDE with additional social features. We built system-of-systems
 adapting and integrating five existing OSS projects: Colab
 (www.github.com/colab), Noosfero (www.noosfero.org), Gitlab (www.gitlab.com),
@@ -138,11 +139,14 @@ multiple components and allowed us to smoothly provide a unified interface for
 final users, including single sign-on and global searches [1]. All integrated
 system represents a total of 106.253 commits and 1.347.421 lines of code.
  
-![The SPB Deployment Pipeline. It started when new code arrived. As the code went through each step, it was tested and improved until finally reaching the production environment. At this point, we would restart the pipeline to release new versions.](figures/pipeline_3.png)
+![The SPB Deployment Pipeline.](figures/pipeline_3.png)
  
 The SPB portal deployment follows a typical CD pipeline [3], adapted to the
 technical and organizational context of our project and the use of OSS best
-practices, as presented in Figure 1.
+practices, as presented in Figure 1. It started when new code arrived; and when
+it reach the production environment, we would restart the pipeline to release
+new versions.
+
  
 ### Automated Tests
  
@@ -298,15 +302,7 @@ process on-the-fly.
  
 ### Overcoming Mistrust
  
-<!-- Tente reduzir, indo direto ao ponto para os Takeaways -->
-Adopting an unfamiliar approach requires trust. In the Ministry, traditionally,
-a software was the product delivered at the end of a development contract; they
-expected and were prepared to validate and deploy a single deliverable. This
-process was not adequate for the SPB: because the SPB portal is a
-system-of-systems, the steady growth of its complexity made large deliveries
-unsustainable.  Therefore, the CD approach was necessary, but how to build
-trust and gain autonomy to implement a process that was not yet part of the
-dynamics of the Ministry?
+Adopting an unfamiliar approach requires trust. Ministry staff, traditionally, expected and were prepared to validate and deploy a single deliverable. However, the steady growth of SPB complexity made large deliveries unsustainable. The CD approach was necessary. Therefore, we use the following approaches to made this new dynamic in the Ministry possible:
  
 1. _Demonstrate actual results, do not simply tell._ Initially, we did not have
 access to the Ministry infrastructure, so we created our own validation
...	...	@@ -130,6 +130,7 @@ project, we became active participants in the deploy operations.
130	130
131	131	## Our Continuous Delivery Pipeline
132	132
	133	+<--! discutir a precisão dos dados -->
133	134	SPB portal is a CDE with additional social features. We built system-of-systems
134	135	adapting and integrating five existing OSS projects: Colab
135	136	(www.github.com/colab), Noosfero (www.noosfero.org), Gitlab (www.gitlab.com),
...	...	@@ -138,11 +139,14 @@ multiple components and allowed us to smoothly provide a unified interface for
138	139	final users, including single sign-on and global searches [1]. All integrated
139	140	system represents a total of 106.253 commits and 1.347.421 lines of code.
140	141
141		-![The SPB Deployment Pipeline. It started when new code arrived. As the code went through each step, it was tested and improved until finally reaching the production environment. At this point, we would restart the pipeline to release new versions.](figures/pipeline_3.png)
	142	+![The SPB Deployment Pipeline.](figures/pipeline_3.png)
142	143
143	144	The SPB portal deployment follows a typical CD pipeline [3], adapted to the
144	145	technical and organizational context of our project and the use of OSS best
145		-practices, as presented in Figure 1.
	146	+practices, as presented in Figure 1. It started when new code arrived; and when
	147	+it reach the production environment, we would restart the pipeline to release
	148	+new versions.
	149	+
146	150
147	151	### Automated Tests
148	152
...	...	@@ -298,15 +302,7 @@ process on-the-fly.
298	302
299	303	### Overcoming Mistrust
300	304
301		-<!-- Tente reduzir, indo direto ao ponto para os Takeaways -->
302		-Adopting an unfamiliar approach requires trust. In the Ministry, traditionally,
303		-a software was the product delivered at the end of a development contract; they
304		-expected and were prepared to validate and deploy a single deliverable. This
305		-process was not adequate for the SPB: because the SPB portal is a
306		-system-of-systems, the steady growth of its complexity made large deliveries
307		-unsustainable. Therefore, the CD approach was necessary, but how to build
308		-trust and gain autonomy to implement a process that was not yet part of the
309		-dynamics of the Ministry?
	305	+Adopting an unfamiliar approach requires trust. Ministry staff, traditionally, expected and were prepared to validate and deploy a single deliverable. However, the steady growth of SPB complexity made large deliveries unsustainable. The CD approach was necessary. Therefore, we use the following approaches to made this new dynamic in the Ministry possible:
310	306
311	307	1. _Demonstrate actual results, do not simply tell._ Initially, we did not have
312	308	access to the Ministry infrastructure, so we created our own validation
...	...