From 3147744e2029d88253be8ee2c35486506ed2dec1 Mon Sep 17 00:00:00 2001 From: Siqueira Date: Mon, 31 Jul 2017 23:18:57 -0300 Subject: [PATCH] Small fix on benefit --- ieeeSW/releaseEng3/IEEE_ThemeIssue_ReleaseEng_CD.md | 31 +++++++++++++++---------------- 1 file changed, 15 insertions(+), 16 deletions(-) diff --git a/ieeeSW/releaseEng3/IEEE_ThemeIssue_ReleaseEng_CD.md b/ieeeSW/releaseEng3/IEEE_ThemeIssue_ReleaseEng_CD.md index 10adf50..d4a01b9 100644 --- a/ieeeSW/releaseEng3/IEEE_ThemeIssue_ReleaseEng_CD.md +++ b/ieeeSW/releaseEng3/IEEE_ThemeIssue_ReleaseEng_CD.md @@ -192,23 +192,23 @@ Working with the government, we noticed the following additional benefits. Responsiveness was one of the direct benefits of adopting the CD pipeline. The ability to react quickly to changes requested by the government was vital for the renewal of the project over the years. Every meeting with the government -leader was resulted in new requirements, most of them motivated by political +leader resulted in new requirements, most of them motivated by political needs. These constant changes in requirements and priorities caused discomfort between the government and the development team. For -example, once it was demanded a completely layout change because another +example, once it was demanded a complete layout change because another government leader suddenly decided to make a marketing campaign about the new SPB portal. They would use undelivered requirements as a means to justify the -lack of financial support, which was already planned in the first place. We believed that if we took too +lack of financial support, which was already approved in the first place. We believed that if we took too long to attend their demands, the project would end. CD helped us keep the production environment up-to-date, even with partial versions of a feature. That -way, we always had something to show on meetings, reducing anxiety to get the platform concluded. the developers more confident the +way, we always had something to show on meetings, reducing anxiety to get the platform concluded. For our team, it made the developers more confident that the project would last a little longer and they would not go looking for other jobs. ### Shared responsibility Before the adoption of CD, the development team could not track what happened to the code -after its delivery, since government technicians were the only responsibles +after its delivery, since government technicians were the only responsible for deploying the project. The implementation of the referred approach influenced developers on taking ownership of the project because it made them feel equally responsible for what was getting into production. @@ -217,19 +217,19 @@ Interestingly, the CD pipeline had the same effect on the team of requirement an They were an active part of the pipeline and became more engaged on the whole process. After the incorporation of the pipeline into the work process, analysts became more active in opening and discussing issues during the platform evolution. -Additionally, developers worked to improve the CD pipeline in -order to speed up the process of making available, in the production environment, +Additionally, developers worked to improve the CD pipeline +to speed up the process of making available, in the production environment, new features for the platform. ### Synchronicity between government and development Despite the positive impacts that the CD pipeline brought to the project, its -implementation was not easy at first. The good performance of the CD pipeline -depended on the synchronicity between the teams of developers and government -analysts, , so that the latter is prepared to start a step as soon as the -former concludes the previous step, and vice versa. Initially this concern was not +implementation was not easy at first. The CD pipeline performance +depended on the synchronicity between developers and government +analysts, so that the latter were prepared to start a step as soon as the +former concluded the previous step, and vice versa. Initially, this concern was not contemplated in the agenda of the governmental team, which generated delays in -the validation of the new features of the release. This situation combined with +the validation of new features. This situation combined with governmental bureaucracy (up to 3 days) to release access to the production environment resulted in additional delays for the deployment step to begin. This problem was softened when the analysts realized the impact of @@ -240,7 +240,7 @@ work schedule and to request the access to production in time. Continuous delivery was also a tool that helped to strengthen trust in the relationship between developers and government analysts, as well as between the -latter group and its superiors. Before using CD, analysts had access to the +analysts group and its superiors. Before using CD, analysts had access to the features developed only at the end of the release, usually every four months. However, this periodicity did not meet the requirements of their leaders, who demanded monthly reports on the progress of the project. @@ -250,9 +250,8 @@ available, allowing analysts to perform small validations over time. As they validated functionalities and sent feedback to developers, patches were developed and new versions were packaged and deployed to the VE quickly, steadily, and reliably. The constant monitoring of the development work brought -greater security to the governmental nucleus and improved the interactions of -this with our development team. - +greater security to the governmental nucleus and improved the interactions +with our development team. ## Challenges -- libgit2 0.21.2