Download as
Browse Code »

Commit 3147744e2029d88253be8ee2c35486506ed2dec1

Authored by Rodrigo Siqueira de Melo
1 parent a7fe3919
Exists in master and in 3 other branches oss_2018, oss_2018_siqueira, rework_case_study

Small fix on benefit

Showing 1 changed file with 15 additions and 16 deletions   Show diff stats
ieeeSW/releaseEng3/IEEE_ThemeIssue_ReleaseEng_CD.md
  Diff comments   View file @3147744
... ... @@ -192,23 +192,23 @@ Working with the government, we noticed the following additional benefits.
192 192 Responsiveness was one of the direct benefits of adopting the CD pipeline. The
193 193 ability to react quickly to changes requested by the government was vital for
194 194 the renewal of the project over the years. Every meeting with the government
195   -leader was resulted in new requirements, most of them motivated by political
  195 +leader resulted in new requirements, most of them motivated by political
196 196 needs. These constant changes in requirements and priorities caused discomfort
197 197 between the government and the development team. For
198   -example, once it was demanded a completely layout change because another
  198 +example, once it was demanded a complete layout change because another
199 199 government leader suddenly decided to make a marketing campaign about the new
200 200 SPB portal. They would use undelivered requirements as a means to justify the
201   -lack of financial support, which was already planned in the first place. We believed that if we took too
  201 +lack of financial support, which was already approved in the first place. We believed that if we took too
202 202 long to attend their demands, the project would end. CD helped us keep the
203 203 production environment up-to-date, even with partial versions of a feature. That
204   -way, we always had something to show on meetings, reducing anxiety to get the platform concluded. the developers more confident the
  204 +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
205 205 project would last a little longer and they would not go looking for other
206 206 jobs.
207 207  
208 208 ### Shared responsibility
209 209  
210 210 Before the adoption of CD, the development team could not track what happened to the code
211   -after its delivery, since government technicians were the only responsibles
  211 +after its delivery, since government technicians were the only responsible
212 212 for deploying the project. The implementation of the referred
213 213 approach influenced developers on taking ownership of the project because it
214 214 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
217 217 They were an active part of the pipeline and became more engaged on the whole process.
218 218 After the incorporation of the pipeline into the work process, analysts
219 219 became more active in opening and discussing issues during the platform evolution.
220   -Additionally, developers worked to improve the CD pipeline in
221   -order to speed up the process of making available, in the production environment,
  220 +Additionally, developers worked to improve the CD pipeline
  221 +to speed up the process of making available, in the production environment,
222 222 new features for the platform.
223 223  
224 224 ### Synchronicity between government and development
225 225  
226 226 Despite the positive impacts that the CD pipeline brought to the project, its
227   -implementation was not easy at first. The good performance of the CD pipeline
228   -depended on the synchronicity between the teams of developers and government
229   -analysts, , so that the latter is prepared to start a step as soon as the
230   -former concludes the previous step, and vice versa. Initially this concern was not
  227 +implementation was not easy at first. The CD pipeline performance
  228 +depended on the synchronicity between developers and government
  229 +analysts, so that the latter were prepared to start a step as soon as the
  230 +former concluded the previous step, and vice versa. Initially, this concern was not
231 231 contemplated in the agenda of the governmental team, which generated delays in
232   -the validation of the new features of the release. This situation combined with
  232 +the validation of new features. This situation combined with
233 233 governmental bureaucracy (up to 3 days) to release access to the production
234 234 environment resulted in additional delays for the deployment step to begin.
235 235 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.
240 240  
241 241 Continuous delivery was also a tool that helped to strengthen trust in the
242 242 relationship between developers and government analysts, as well as between the
243   -latter group and its superiors. Before using CD, analysts had access to the
  243 +analysts group and its superiors. Before using CD, analysts had access to the
244 244 features developed only at the end of the release, usually every four months.
245 245 However, this periodicity did not meet the requirements of their leaders, who
246 246 demanded monthly reports on the progress of the project.
... ... @@ -250,9 +250,8 @@ available, allowing analysts to perform small validations over time. As they
250 250 validated functionalities and sent feedback to developers, patches were
251 251 developed and new versions were packaged and deployed to the VE quickly,
252 252 steadily, and reliably. The constant monitoring of the development work brought
253   -greater security to the governmental nucleus and improved the interactions of
254   -this with our development team.
255   -
  253 +greater security to the governmental nucleus and improved the interactions
  254 +with our development team.
256 255  
257 256 ## Challenges
258 257  
... ...