As part of the release the notification task is used to communicate to stakeholders. However, we need share some information with that mail that is stored in an excel file. How can we attach that excel file to the e-mail?
I am currently investigating this, the best idea I have at the moment is some form of central storage for the attachment outside of XL Release and referencing it in the email. If the file is added programatically we may have other options for providing access to it, looking into that now.
Can I confirm your use case
- actors in the release upload an excel file as part of one of their manual tasks
- that file is required to be distributed to a wider audience than has access to XL Release
- Is XL Release to be your strategic storage location for release specific evidence?
- Is there any form of acknowledgement or other activity required post receipt of this file, or is it for information only?
We have the same use case. There are artifacts that if we would attach screenshots to the releases, it would help us when it comes to audits. For example, if automated tests run, attach a pdf of tests and results at a more granular level. Or if a task is capturing a view of the current state of folders/files on a server, attach it to the task before and after release is executed.
While I would not call XLR our strategic storage location for release specific evidence, it makes sense to us that we have all these artifacts in one location so when we have to pull hundreds of these items, they are traceable and in the same place, which makes it easy to provide as evidence for auditor for the lifecycle, vs having to go to a whole bunch of different applications to pull in documents.
No acknowledgement or other activity is required post receipt of these files as it is for information only. Once attached, the remaining tasks can continue progressing, etc.
Indeed we now send an email with a path to the file. However that file is with every release in a different date folder. So we made a reference to the filepath where users need to navigate manually to that folder taking the date into consideration. The file contains passwords to the production environments.
Our release team changes per sprint,so we would like to send the mail with an attachement containing the passwords to dedicated recipients of that particular release so the don’t need to navigate manually to a folder. The release participants have all access to xl release.
So the idea is: release owner requests all necessary passwords,place the passwords in a file at central location where access is limted and xl release distributes the file to the dedicated recipients that play a role in the deployment of the configuration.
Re you questions.
Xl release is the strategic tool for orchestrating the release process and is the audit trail of which release steps have been executed or not.
It is for information only, without the passwords installers can not deploy the configuration items.
Hope this clarifies sufficiently. If not please let me know.
By design the XL Release dashboards are there to provide a view of this evidence by connecting to testing tools and retrieving data. (See the blackduck, sonarqube, fortify etc plugins). I understand the usecase and recognise the appeal to have files etc attached but there is no real provenance that these are indeed real evidences which is why I personally would be reluctant to rely on this approach. Have you looked at querying the data from a test tool using a custom plugin (in the absence of one in the community?) . What tools are you using to run your unit tests? Jenkins?
I personally like the idea of the release dashboard being used as a pointer to all the evidences gathered in a release, but also comments displaying data can work as a task executes - this provides as snapshot of data at the time the task itself was run.
Your comments about the requirements of an auditor is definitely timely, you will see this as a theme in the products - watch this space on that front.
That is a very specific use-case and generally not one that I think we have considered. Our users tend to interact with password vaults for security reasons rather than emailing around a file, so I can understand you wanting to manage that within the security of a release.
It’s certainly possible to derive the location of your storage location using (for example) a script task that determines the date string and creates the link accordingly. If you want some inspiration on how to write script tasks there are a bunch of (unrelated) examples here
I personally would be cautious of sending emails with passwords to your infrastructure to people, there is too much room for interception or unintended sharing. Does your organisation use a password manager?
If you want the file to sit within the release pipeline as an attachment be aware there is no control of that file after it has been downloaded by an individual which is why my recommendation is a central restricted location for this data. We do however have APIs that allow you to add an attachment programatically. Is this something you are able to look into?
Thank you for your reply. I see your position of using the release dashboard as a pointer to all evidence gathered. Appreciate your feedback.