diff --git a/ieeeSW/releaseEng3/IEEE_ThemeIssue_ReleaseEng_CD.md b/ieeeSW/releaseEng3/IEEE_ThemeIssue_ReleaseEng_CD.md index 45ed601..fbf8f3d 100644 --- a/ieeeSW/releaseEng3/IEEE_ThemeIssue_ReleaseEng_CD.md +++ b/ieeeSW/releaseEng3/IEEE_ThemeIssue_ReleaseEng_CD.md @@ -222,46 +222,50 @@ to production. ### Shared Responsibility -When the government technicians were responsible for deploying the project, the -developers lost track of what happened after code was delivered. After adopting -CD, they felt more responsible for what was getting into production. CD -influenced developers on taking ownership of the project. In the end of the -project, we noticed that the entire team was working to improve the CD pipeline -since they want to their new features in production. - -Interestingly, the CD pipeline also made the government requirements analysts -feel more responsible for the project. They were an active part of the pipeline -and that engaged them on the whole process. In the end, they were even actively -creating issues and discussing them during the development process. - - -[//]: # (TODO - depois deles entrarem de fato no pipeline, ou seja, validar em ambiente de homologação, criando issues e comentando nas issues do repositório é que de nosso processo empírico de desenvolvimento predominou até o fim do processo) - - -### CD pipeline protocol between Government and Development - -In the beginning of the CD pipeline use, a bottleneck arose at the acceptance -tests step due to delays in reviewing new features and starting the next step. -These delays occured because the government analysts, responsible for -reviewing, were sometimes busy or didn't have schedule this work. Furthermore, -after the acceptance of the new code, there was a bureaucracy in the government -IT infrastructure that often made us to wait until 3 days to get the production -environment access and then to start the deployment step. This problem was -softened when we clarify our pipeline for these analysts and they organized -their schedule to speed up reviews and production access requests. - -### Work in small batches developed trust in our relation with government analysts - -In the first three releases, government requirements analysts were validating -all features to be released only at the end of a delivery cycle which often -took almost four months. However their superintendents requested monthly -reports about the project progress and this brought pressure on them which in -turn put it on us. When we started to make continuous deliveries, we really delivered -intermediate and candidate releases. Thus, the analysts could have validate a -small set of features, making possible more accurate feedbacks and better -reports for regular meetings with their superintendents. As a result, we -gained their trust and they also gained trust of their chiefs about the SPB -project management. +Before the adoption of the CD, the developers team could not track what happened to the code +after its delivery, since government technicians were the only responsibles +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. + +Interestingly, the CD pipeline had the same effect on the team of requirements analysts. +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, +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 work of one could be initiated immediately after +the delivery of the work by the other. 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 +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 +these delays on the final product and decided to allocate the revisions in its +scale of work and to request the access to production in time. + +### Strengthening trust in our work relation with the government + +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 +features developed only at the end of the release, usually every 4 months. +However, this periodicity did not meet the requirements of their directors, who +demanded monthly reports on the progress of the project. With the +implementation of the CD, intermediate versions became available, allowing +analysts to perform small validations over time. The constant monitoring of +the development work brought greater security to the governmental nucleus and +improved the interactions of these with the team of developers. + ## Challenges -- libgit2 0.21.2