Feature #1431

Redmine: release ticket status should be updated

Added by Francesco Mangiacrapa about 4 years ago. Updated about 4 years ago.

Status:ClosedStart date:Nov 19, 2015
Priority:NormalDue date:Nov 24, 2015
Assignee:Luca Frosini% Done:

100%

Category:Other
Sprint:zz - UnSprintable
Milestones:
Duration: 4

Description

After a discussion in a meeting @CNR the following status of the (Redmine) Release Tickets were proposed to be added:

  • staging: Etics has built the component which is available on Nexus
  • available in pre-prod: the component is released in pre-production
  • testing in pred-prod: the component is under testing in pre-production
  • ready to release: the component is ready to the release in production

History

#1 Updated by Francesco Mangiacrapa about 4 years ago

  • Description updated (diff)

#2 Updated by Luca Frosini about 4 years ago

  • Status changed from New to In Progress
  • Description updated (diff)

#3 Updated by Luca Frosini about 4 years ago

  • Description updated (diff)

staging is not needed. When the component is under integration it will be compiled in the following night. The version to be deployed in pre-prod is the one provided by night build. (When there is something urgent the version compiled locally is used so that for me this status is not needed) .

Due to the previuos consideration available in pre-prod is not needed and is also an error in my opinion

Ok for testing in pred-prod: the component is under testing in pre-production (means that is deployed in pre-production)
Ok for ready to release: the component is ready to the release in production

After some thoughts I think is wrong add these status in release ticket.This is a deployment issue. For example, if the ticket is in testing in pred-prod the day 3 and the day 4 does not build anymore due to API change from a dependency the new status will be Build Issue. Without reading the full history we lose the situation.
Maybe is better create another ticket to attach to the release ticket, or BETTER add a separated field (list box with a single selection). In that way with the actual query we can monitor the full situation release and deployment of the component.

In this situation I propose that the field of the addition fields can be:
N/A: Not Available (used when the component is not deployed on pre-prod, fro subssytem and master ticket will always have this value).
Deployed In preproduction: The component build by Etics night build or by manual Etics build launch has been get from the developer and deployed in pre-production.
Tested: the component has been tested and the developer and infrastructure manager think that is ready to the release in production.

A final consideration on this procedure: An enabling library which has to be present in all nodes (i.e authorization) MUST be deployed in all nodes, otherwise we recreate the situation of dev. So that for this type of component we must create provision support.
To allow developer to deploy on preproduction all developer ssh keys must be present in the right nodes.
Maybe is better if we rethink a moment about his.

#4 Updated by Francesco Mangiacrapa about 4 years ago

I'm not entirely agree with your comments about staging and **available in pre-prod*

staging is a status which informs the pre-production manager that the component is "stable" and "ready" on Nexus after an night build or remote build (and it should be added in pre-production). It could be omit if the role of the pre-production manager is see "always" the Etics build status and deploy on pre-production "all" built components, but I don't think. Otherwise if each developer is responsible to deploy his "stable" components in pre-production environment then staging is not needed.

Due to the previuos consideration.. Who/What informs a developer/tester that a "stable" component is released on pre-production for testing? Deployed In pre production/Available in pre-prod!

So are OK for me all status above described.

@pasquale.pagano@isti.cnr.it what do you think about?

I'm adding @massimiliano.assante@isti.cnr.it and @roberto.cirillo@isti.cnr.it to discussion

#5 Updated by Massimiliano Assante about 4 years ago

to be honest I don't recall a meeting where we agreed about these statuses.

Ok to discuss about a better way, but we're mixing integration and part of operation (deployment) here.

What does stable mean here?

Who/What informs a developer/tester that a "stable" component is released on pre-production for testing?

A component released on pre-production for testing will never be stable until is tested thoroughly.

In order to not starting an infinite thread and mail exchange , I believe the operation team should meet with 2-3 developers at most an have a face to face meeting to discuss again about this. I suggest to pause the ticket and find a date and time to meet again.

#6 Updated by Francesco Mangiacrapa about 4 years ago

Massimiliano Assante wrote:

to be honest I don't recall a meeting where we agreed about these statuses.

Ok to discuss about a better way, but we're mixing integration and part of operation (deployment) here.

What does stable mean here?

Who/What informs a developer/tester that a "stable" component is released on pre-production for testing?

In this case for "Stable" I meant that the developer does not think that the component will change again so the last Etcis build is "stable"/"ready" to deploy the component in pre-production.

A component released on pre-production for testing will never be stable until is tested thoroughly.

In order to not starting an infinite thread and mail exchange , I believe the operation team should meet with 2-3 developers at most an have a face to face meeting to discuss again about this. I suggest to pause the ticket and find a date and time to meet again.

Ok for me.

#7 Updated by Pasquale Pagano about 4 years ago

thins have always to become complex and bureaucratic just for the sake of discussion.
At Monday meeting I expressed the need to be more agile and I proposed what is contained in this ticket. I left only the details to decide.
Continuos integration and deployment in preproduction is what we need to achieve now.

#8 Updated by Luca Frosini about 4 years ago

  • Due date set to Nov 24, 2015
  • Tracker changed from Support to Feature

#9 Updated by Luca Frosini about 4 years ago

  • % Done changed from 0 to 100
  • Status changed from In Progress to Feedback

Dear ALL,

I updated the Release procedure with the requirement emerged to speed up the release and to solve some of the problems evidenced in the past.

The following status were added:

  • RTD on Preprod ( RTD = Ready To Deploy ): the component has been published on stagin nexus repository (by explicitly launching an etics build on the current release or because the night build succeeded see STAGIN NOTE at the end of this comment fro further details). This is used to notify the portal manager or the preprod infrastructure manager to upgrade that component on preprod, in this case they MUST be added in advance as watcher of the component release ticket. See also Provisioning NOTE at the end of this comment, to check applicability of this status.
    When the developer can update on preproduction the component autonomously it uses directly the Deployed on Preprod status.
    Please note that this status MUST not be used for subsystem release ticket or the master release ticket.

  • Deployed on Preprod : Indicate that the component has been deployed on ALL nodes of preproduction and is up and running.

  • Tested on Preprod : The developer and/or the portal manager or the preprod infrastructure manager are confident that the component behave as expected and can be released as is.

Stagin NOTE:
Yesterday I had a skype call with @gabriele.giammatteo@eng.it to check if is possible configuring nexus to add build number on stagin repository as is already done for snapshot one. After we approve this new procedure the component to deploy both dev and preprod infrastructure MUST be the one downloaded from nexus having the build number.

Provisioning NOTE:
When the deployment of a component involve more than two nodes, an automatic procedure by using provisioning (ansible) MUST be created in advance. The first time this situation is verified, the developer MUST create a ticket for provisioning support. The ticket for provisioning MUST be related to the release ticket. The ticket can only be closed when (all the bullet must be verified):
* the provisioning script has completed (by the developer or by the entitled people)
* a documentation regarding the script has to be created
* the ticket has been updated indicating where the provisioning script is available and where is the documentation
Only when the provisioning ticket is closed the RTD on Preprod status can be set.

#10 Updated by Luca Frosini about 4 years ago

  • Status changed from Feedback to Closed

Also available in: Atom PDF