In VSTS, is it possible to trigger a release upon the completion of another release? I know the release is typically triggered by the completion of a build, but I am wondering if I can trigger one release with another release, for the sake of organizing my processes into multiple releases and linking them together.
Thanks.
That's not a capability at present time, although you could write a custom task using the REST API to accomplish the same thing, or check the marketplace to see if someone has already created a task to do the same.
There are a lot of considerations when you start doing things like this, though. What build are you releasing in your "sub-releases"? The latest one? That build might not be stable enough to deploy. A hard-coded value? That's going to be a thing that people forget to update.
Typically, my approach in situations like this are to break down the releases into different discretely deployable units that have no dependencies on other units. They can be promoted through the stages as necessary. Then, if you have the occasional need to just do everything all together (for example, provisioning a brand new environment), have a "combo" release that encompasses everything. There isn't even a need for duplication with the recent introduction of meta-tasks.
You can try Release Orchestrator extension from the marketplace which adds a task to execute and track progress of multiple release pipelines in Azure DevOps.
Looks like you can use the VSTS Trigger extension from the marketplace to trigger a new build or release from a build or release.
I think an easier option would be to schedule a release. If you create a schedule for the release of each of your application repositories you can ensure that they will all reach the servers at the same time.
Another option is to use stage scheduled triggers.
Related
I am currently working on a project and in this moment we have a Release Candidate, which is supposed to go under an official V&V and then it will undergo a FDA submission (medical devices Software).
At the same time, we need to go ahead with another branch of the same project, adding some features, changing some of the requirements for the features that now are going under V&V, removing some of them.
This means that we will need to add, edit, delete some of our Requirements in DevOps to be aligned with the new features, but we also need to continue managing the requirements that are now valid for the Release Candidate under V&V, even if some of them will not be valid anymore in the new branch.
What would be the best choice to manage this situation with devOps?
In general, how to manage a version that starts from a certain point in the project and follows a partially different path with slight or heavy differences in the requirements?
What we would need is some kind of "versioning" of all the work items (requirements, test cases etc) we have currently in devOps. Is that possible?
Thank you!
TLDR;
Does Azure DevOps have a recommended built in way of marking Resolved Work Items as being actively tested as opposed of being in the queue for testing?
Details
My team is using Azure DevOps with Agile workflow.
This means that out-of-the box a user story goes through the following states
New -> Implementation started ->
Active -> Code complete ->
Resolved -> Acceptance tests passed ->
Closed
This is nicely shown at learn.microsoft.com:
Testing happens in when the story (or bug) is in the Resolved state.
The out of the box board has 4 lanes.
When looking at the board (or even in queries) I'm having trouble seeing what is being actively tested.
For example, if there are 2 resolved items it is not clear which one is being actively worked on and which one is waiting to be picked up.
Showing what is being tested seems like a common desire and my intuition is that the solution for my problem is built in. I want to avoid customising the workflow (and adding a new state called Testing).
Cross-post from pm.stackexchange.com
I would suggest using the Kanban board and adding a column named Testing. This won't require adding a custom state to your workflow but does give you more visibility into the state of a work item.
You can also split columns into Doing and Done so you know where an item is stuck in the flow of your work.
In my company we have been in the same situation.
I like #Wouter's answer and I think it deserves upvotes, but I just want to expose it in another way (it depends on your needs, maybe they are similar to mine).
In my company we have a board with a column called "Testing" (divided into "Doing" and "Done") but this board is only for developers, for their tests. But in our development lifecycle there is another step called "UAT" where the software is deployed in a test environment called "uat" ... and is tested by business users who run their own acceptance tests.
Now, we developers don't want these business users to use Azure DevOps Boards or, worse, change work item states (we tried, it can be a mess).
We want to isolate their actions on a Test Plan.
Therefore, when the release pipeline deploys in the "uat" stage N work items, it also creates a Test Plan with N test cases (manual, not automated) that our business users must validate with Pass / No pass.
When all test cases have been validated, we can deploy the build to Production.
Maybe this suites you.
We have multiple release pipelines (Dev, QA, etc.). After a given release, we want to update the State for each work item associated with the release. I understand that can cause problems if we manually re-release, or re-build. I see third party marketplace extensions that could do it, but is there a way to do it from something built into DevOps pipelines?
I've tried every out-of-the-box feature I can find to accomplish this and found my way blocked.
It seems the options are: use the extensions others have written, write your own, or dive into the REST API.
We are currently using the WorkItem Updater extension for production stages.
We are using vsts releases to manage our deployments.
I need to deploy to hundreds of instances, each one with at least two environments (UAT and prd).
Our pipeline looks like dev -> qa-> customer, where customer can be hundreds. So it is unmanageable to have two environments per client or to have one individual release definition per customer.
If I could dynamically change a variable for the customer environment at the moment the release is in progress, by user intervention on that variable, then I could have only one environment definition that could be used to deploy to any of my instances.
Does anyone has an idea of how to achieve that without a complex PowerShell? Is there anyway to dynamically change variables at run time in a vsts release?
Digging a little more, it turns out that the path I could follow is to change a variable on a specific release, and that make the tenants environment to use that variable to deploy to the correct target.
It actually is a workaround, because release don't have a way to define a variable value when creating a release from a release definition, like you can do in the build system.
I need a tool that will graphically represent our build pipeline. The below screenshots of ThoughtWorks Go and the Jenkins Pipeline plugin illustrate almost exactly what I want it to look like.
The problem is that we already use Jenkins for our builds and deployments, along with a few other custom tools for orchestration type duties. We don't want a pipeline tool to do the builds or deployments itself, it just needs to invoke Jenkins! I tried out Go, and the first thing it asked for is where my source code is and how to build it. I couldn't get Go to work in a way where Jenkins does the builds but Go creates the pipeline.
I've also experimented with the Jenkins Pipeline plugin, but it's very limiting. For one, it doesn't work with the Join plugin (so we can't have jobs run in parallel, which is a requirement). It also assumes that all of our tasks happen in Jenkins (Jenkins can't see outside of our test lab and into our production environment). I don't know if this is a viable option either.
So, does anyone have any recommendation for some pipeline tools that will do what I'm looking for?
Edit (03/2018)
Since writing this question in 2012 and answering it in 2014, numerous tools have come online to support what I originally wanted. Jenkins now supports scripted pipelines natively and has an excellent UI (Blue Ocean) for rendering them. Those stumbling on this question should consider using these for their pipeline needs.
https://jenkins.io/doc/book/pipeline/
https://jenkins.io/projects/blueocean/
End edit
(Old answer)
It didn't exist when I asked the question, but Jenkins' Build Flow Plugin does exactly what I needed, and creates pipeline views very well.
https://wiki.jenkins-ci.org/display/JENKINS/Build+Flow+Plugin
Jenkins/Hudson can certainly be used to achieve a real pipeline.
You could use Go if you used a dummy material (an empty git repo, for example), and then used the API to trigger a pipeline and upload artifacts.
But, that's quite some effort, and you should probably only do that if you have a very good reason otherwise to use Go.
You can try with GoCD pipeline. It has very nice features for continuous delivery and has nice dashboard also which shows real time flow and status. Give a try.