diff --git a/ieeeSW/releaseEng3/IEEE_ThemeIssue_ReleaseEng_CD.md b/ieeeSW/releaseEng3/IEEE_ThemeIssue_ReleaseEng_CD.md index aba1c7a..6da1e02 100644 --- a/ieeeSW/releaseEng3/IEEE_ThemeIssue_ReleaseEng_CD.md +++ b/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 - -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 -- libgit2 0.21.2