For a request by Kevin Kocher
Problem Use Case
We've had a number of releases that get slowed down by RE/RM entering invalid credentials at the start and/or during the release that then fall into XLD tasks, most of the time many XLD tasks, and then fail. The credentials may be valid in XLD, just not valid for the current environment being deployed to. This can lead to a lot of confusion, for example, when the deploy tasks in one environment have already succeeded, but now the next environment in the pipeline fails with those same credentials.
Some attempt has already been made to try and minimize the deployment failures in XLR's XLD Deploy Task. It essentially revolves around the built-in XLR user input task, and the community plug-in "Get Latest Version"
Once the input task is complete, we essentially hard-code a known application into the Get Latest Version task, pass the credentials the user just entered, and see if the task succeeds in getting the latest version of the hard-coded application.
The idea here is that if the credentials don't allow the user access into XLD to run this task, it will fail and we can ask the user to re-enter them before moving onto the actual deploy tasks.
In practice, there have been a few problems with this approach.
• 1. The validation is only on the credentials themselves. There's no validation that the credentials supplied will work with the XLD environment about to be deployed to. In practice we've seen good credentials get entered, the check passes, but then all the deployments fail because the creds supplied don't work in production.
• 2. When the credentials fail, it's not very intuitive on how to re-enter them. Because the input task has already succeeded, and all the deploy tasks have already failed, really the only way to “try again” is to restart the phase. Power users of XLR can do this correctly, but not everyone involved with a reelase necessarily understands our instructions
• 3. For some deployments the failures will occur in "everywhere at once" . This happens when individual applications are deployed in parallel. All of a sudden there are 40+ simultaneous failures to the release and many times each one has to have the proper creds entered on an individual basis. It's time consuming, and looks really bad from an end user's perspective.
We’re trying to have discussions about what a sound approach would be that is both secure and “easy to use”. Not only for successful cred validation, but also for easy retries.
To circumvent all that retry we’re also considering defining a single user in XLD with “deploy everywhere” access, but we don’t really know how to secure any XLR task that might use those creds.
Someone with edit access to the release as a whole could go into the task to modify the app, env, or dupe/change the task type, and be malicious (accidentally or on purpose). Maybe if there was a way to control access down to the task level?
Would you have any suggestions or other solutions in the works or implemented that might help us reduce these types of failures?
We can create a custom tasks call it validate deployment users.. put it as the first task in releases.That task would search for all the XLD tasks and makes a query each with they deployment app/env/creds and prints a report of which one would fail. It can pass if everything works or fail there printing the report about the failing task. The folks can then correct those tasks, retry this validate task and if it passes, they should be all set
Prototype ( works on 6.1 )
Using the above approach, i wrote a script that can be used inside a script task as the very first task in your release. the task would look out for all XL Deploy tasks and try to capture the information from them, make a call to verify the deploy#initial permission for the credentials on that environment and report it back in a summary. This ofcourse can be wrapped around nicely in a plugin and then used. Also would require a little bit of change to make it compatible with XLR 6.0 and below.
Difference in 6.1 vs 6.0
- if str(t.taskType) == "xldeploy.Deploy":
- print t.pythonScript.getProperty("username")
- t.pythonScript.getProperty("server") gives you server configuration object and you can do s.username, s.password , s.url to get the values
6.0 and below