Commit c1ec28b3d2da4d815a2c6d3bef62d8b22731323a

Authored by Paulo Meireles
1 parent e732ed58

[ieeeSW] more improvements and less words

ieeeSW/releaseEng3/IEEE_ThemeIssue_ReleaseEng_CD.md
@@ -130,6 +130,7 @@ project, we became active participants in the deploy operations. @@ -130,6 +130,7 @@ project, we became active participants in the deploy operations.
130 130
131 ## Our Continuous Delivery Pipeline 131 ## Our Continuous Delivery Pipeline
132 132
  133 +<--! discutir a precisão dos dados -->
133 SPB portal is a CDE with additional social features. We built system-of-systems 134 SPB portal is a CDE with additional social features. We built system-of-systems
134 adapting and integrating five existing OSS projects: Colab 135 adapting and integrating five existing OSS projects: Colab
135 (www.github.com/colab), Noosfero (www.noosfero.org), Gitlab (www.gitlab.com), 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,11 +139,14 @@ multiple components and allowed us to smoothly provide a unified interface for
138 final users, including single sign-on and global searches [1]. All integrated 139 final users, including single sign-on and global searches [1]. All integrated
139 system represents a total of 106.253 commits and 1.347.421 lines of code. 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 The SPB portal deployment follows a typical CD pipeline [3], adapted to the 144 The SPB portal deployment follows a typical CD pipeline [3], adapted to the
144 technical and organizational context of our project and the use of OSS best 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 ### Automated Tests 151 ### Automated Tests
148 152
@@ -298,15 +302,7 @@ process on-the-fly. @@ -298,15 +302,7 @@ process on-the-fly.
298 302
299 ### Overcoming Mistrust 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 1. _Demonstrate actual results, do not simply tell._ Initially, we did not have 307 1. _Demonstrate actual results, do not simply tell._ Initially, we did not have
312 access to the Ministry infrastructure, so we created our own validation 308 access to the Ministry infrastructure, so we created our own validation