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.
Related
I am able to pass a Variable group or a Schedule toa release pipeline using REST API using "PUT". But the problem is this will edit the release definition. I would like to know is this a good practice of editing the release definition using REST API to achieve this ??
Asking questions about something being good is often subjective. I would say that it depends what your actual end goal is. If you have n release pipelines where n is a large number, and updates to x number of those release pipelines are all the same, then scripting the edit is a good way to manipulate the release definitions as your organization or team requirements evolve. If you're talking about regular and/or frequent manipulations to the release definitions for some ambiguous or ill-defined part of your process or business culture, then you might want to ask about those requirements and why the exist and force you to change your Build/Release pipeline. Those requirements may need to continue to exist, and in such cases, I would suggest (if possible) designing the pipeline is such a way that other tooling can use the pipeline as it is through the REST api to create RELEASES to meet the requirements for alternate variables or scheduling.
Accessing the pipeline through the REST api allows your process to be "flexible", yet insisting on as much consistency as possible over time will be what builds developer and stakeholder trust in the system to NOT be the cause of quality issues.
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.
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.
The shop I work for is using jenkins for continuous integration and its promoted builds plugin to deploy build artifacts. However, we're having trouble managing this set up as the number of configurations grows. So my question is:
How can I set up a handy CI system from which I can deploy various artifacts in various configurations without manually scripting every possible combination?
Some more details:
Let's say I have build configurations (i.e. branches) A, B and C. There are three deployment targets I, J and K (say for various clients or consumers). Finally, each deployed instance has various services X, Y and Z (e.g. web-site, background tasks and data-service). The various services are usually promoted together; but sometimes, particularly to get hotfixes out, they're not.
Currently, we have promotions for each of these combinations. So to install a typical build I'd need to run promotions J/X, J/Y and J/Z on config C. The number of services is unfortunately rising, and getting all those configurations in jenkins without making any error, and furthermore ensure that none of the components are forgotten or mixed up when deployment comes around is getting tricky. And of course, there are more than three build configs and more than three targets, so it's all getting out of hand.
Some options that don't quite work:
Parametrized promotions to disable various components. Jenkins allows parametrized promotions, but the values are fixed the first time you promote. I could remove a degree of freedom by just promoting J and setting some parameters, but if a later version breaks, I can't rollback only the component that broke, I need to rollback the entire deployment.
Dependant, parametrized builds. Jenkins doesn't seem to support parameters to choose which build to depend on, and if you manually code the options then of course the "run" selection parameter can't work.
What I'd really want:
After a build is manually accepted as ready for deployment, it should be marked as such including an argument for which target and arguments for which components.
the installation history is logged per-component per-target, not (only) per-build.
There may be some plugins to help, but you also may be approaching the point where looking at commercial tools is appropriate. I work for a build/deploy vendor (Urbancode) so by all means take this with a giant grain of salt.
We generally see people have different build types (or branches) for a single project and group those as a single 'project' with multiple 'build workflows' using the same basic configuration with some per workflow parameterization. Really simple reuse of process.
The number of services is unfortunately rising, and getting all those configurations in jenkins without making any error, and furthermore ensure that none of the components are forgotten or mixed up when deployment comes around is getting tricky. And of course, there are more than three build configs and more than three targets, so it's all getting out of hand.
If the challenge here is that you have multiple web services and promotions (especially to production) involve pushing lots of stuff, at specific versions, in a coordinated manner you're hitting the standard use case for our application release automation tool, uDeploy. It's conveniently integrated with Jenkins. It also has really nice tracking of what version of what went to what deployment target, and who ran that process.
I have decided to finally nail down my team's deployment processes, soup-to-nuts. The last remaining pain point for us is managing database and runtime data migration/management. Here are two examples, though many exist:
If releasing a new "Upload" feature, automatically create upload directory and configure permisions. In later releases, verify existence/permissions - forever, automatically.
If a value in the database (let's say an Account Status of "Signup") is no longer valid, automatically migrate data in database to proper values, given some set of business rules.
I am interested in implementing a framework that allows developers to manage and deploy these changes with the same ease that we manage and deploy our code.
So the first question is: 1. What tools/frameworks are out there that provide this capacity?
In general, this seems to be an issue in any given language and platform. In my specific case, I am deploying a .NET MVC2 application which uses Fluent NHibernate for database abstraction. I already have in my deployment process a tool which triggers NHibernate's SchemaUpdate - which is awesome.
What I have built up to address this issue in my own way, is a tool that will scan target assemblies for classes which inherit from a certain abstract class (Deployment). That abstract class exposes hooks which you can override and implement your own arbitrary deployment code - in the context of your application's codebase. the Deployment class also provides for a versioning mechanism and the tool manages the current "deployment version" of a given running app. Then, a custom NAnt task glues this together with the NAnt deployment script, triggering the hooks at the appropriate times.
This seems to work well, and does meet my goals - but here's my beef, and leads to my second question: 2. Surely what I just wrote has to already exist. If so, can you point me to it? and 3. Has anyone started down this path and have insight into problems with this approach?
Lastly, if something like this exists, but not on the .NET platform, please still let me know - as I would be more interested in porting a known solution than starting from zero on my own solution.
Thanks everyone, I really appreciate your feedback!
Each major release, have a script to create the environment with the exact requirements you need.
For minor releases, have a script that is split into the various releases and incrementally alters the environment. There are some big benefits to this
You can look at the changes to the environment over time by reading the script and matching it with release notes and change logs.
You can create a brand new environment by running the latest major and then latest minor scripts.
You can create a brand new environment of a previous version (perhaps for testing purposes) by specifying it to stop at a certain minor release.