From 546c15bb4158a4e8afc710695b0f782164ae3968 Mon Sep 17 00:00:00 2001 From: Melissa Wen Date: Tue, 14 Nov 2017 17:00:23 -0200 Subject: [PATCH] [i3eSW] Grammarly Pipeline --- ieeeSW/releaseEng3/IEEE_ThemeIssue_ReleaseEng_CD.md | 77 +++++++++++++++++++++++++++++++++++++---------------------------------------- 1 file changed, 37 insertions(+), 40 deletions(-) diff --git a/ieeeSW/releaseEng3/IEEE_ThemeIssue_ReleaseEng_CD.md b/ieeeSW/releaseEng3/IEEE_ThemeIssue_ReleaseEng_CD.md index 244b219..34d737e 100644 --- a/ieeeSW/releaseEng3/IEEE_ThemeIssue_ReleaseEng_CD.md +++ b/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 -- libgit2 0.21.2