We are using Azure Devops with Octopus deploy.
I have integrated the release steps, and release creation as well as release to first environment (Development in my case) is happening without any issue.
Issue is with subsequent releases.
Release fails in Semantic Versioning check of release name.
'1.2.1023.0508-09' is not a valid version string
at Octopus.Client.Model.SemanticVersion.Parse(String value, Boolean
preserveMissingComponents)
In the first stage, I am creating Octopus release, and deploying to Development environment in the same task (using Create Octopus Release task in Azure devops)
create-release "--project=<projectName>" "--releaseNumber=1.2.1023.0508-09" "--server=<serverName>" "--apiKey=***" --enableServiceMessages "--deployTo=Development" --progress "--releaseNotesFile=<path>"
This step is successful.
In the next stage, I have tried 2 variations,
Promote Release
promote-release "--project=projectName" "--server=serverName"
"--apiKey=***" "--from=Development" "--to=envName"
Deploy Release
deploy-release "--project=projectName" "--releaseNumber=latest"
"--server=serverName" "--apiKey=***" "--deployTo=envName"
Both of them giving same error, saying release name is not a valid version string.
My confusion is, if the name is incorrect, even the first deployment should fail.
If it's correct and allowed, then subsequent stage release should also succeed.
If any one has faced such a issue before, or can add in some pointers to resolve this issue, it will be very helpful.
This sounds like a bug but I'd need more time to reproduce and verify. Can you share what version of Octopus and the Octopus Extension you are using?
My best suggestion to get going with this is to base the release number off of your Azure DevOps build number and use that variable to control what version is getting deployed. Using the 'latest' version could backfire if you have other releases created in between your stages.
If you can set your Azure DevOps build number to be in the same format that you want your Octopus release number (1.2.1023.0508-09), you can use the following commands to build and promote a release.
create-release "--project=<projectName>" "--releaseNumber=$(Build.BuildNumber)" "--server=<serverName>" "--apiKey=***" --enableServiceMessages "--deployTo=Development" --progress "--releaseNotesFile=<path>"
deploy-release "--project=projectName" "--releaseNumber=$(Build.BuildNumber)" "--server=serverName" "--apiKey=***" "--deployTo=envName"
This will make sure that you are promoting the same release that was created in the pipeline.
Just in case if someone came here looking for solution, below are the steps I took to solve the problem,
For first stage (dev in my case), create a new release. If you have multiple tenants, add them. Do not forget to add Package Version. This is especially needed when you have multiple versions of artifacts getting created. I faced hard time resolving this. if you do not add PackageVersion, latest available artifact is picked.
For further stages, DO NOT promote release. Instead, deploy release. This way, you can pass the same release number as configured in first stage. In my case, I kept the stage name same as my environment name. So I was able to use variable for env as well. I copied this stage for 4 different environments.
Related
I am working for a company that develops a lot of apps and we use Azure devops portal for all of our pipeline releases etc.
So, the general flow is that a developer will create a branch to do the development on and change the code on that branch. They would like to deploy that branch before it is merged back into the development line from a pipeline, rather than from visual studio, which they currently do. So, it's about giving the developer to the option to choose which branch to deploy from.
Has anyone done something similar or point me in the right direction to how I could go about this?
When creating the release, currently there is no build-in feature to choose which branch to deploy from, the release pipeline works with the corresponding source Artifacts configuration.
A good approach for your scenario is referring to the build id on your build pipeline (instead of release pipeline).
When running the build pipeline, you could choose the target branch and record the build id for this run.
In your release pipeline, you could check whether the source Artifacts is from your target branch by checking the build id.
I've been setting up a build pipeline which included a Nuget Restore task.
I followed the instructions at https://learn.microsoft.com/en-us/azure/devops/pipelines/packages/nuget-restore?view=azure-devops but the pipeline stalled for long enough for me to cancel it.
Looking at a build pipeline already in place for another project, I noticed version 0 of the Nuget Restore task was being used whereas the one I was trying to figure was version 2.
Having altered my build pipeline to use version 0 of the task, the build pipeline now completes in a reasonable time.
The main question I have regards the fact that I struggle find documentation on the Devops build tasks and when I do there is little explanation of what all the fields and options are used for when to use the different versions.
Can anyone recommend a resource for that?
Failing that can anyone offer an insight as to what is the difference between each version of the Nuget Restore task and when to use each?
Thanks
From your description, I think the 'version' means this, right?
If so, when you change the command from 2 to 0, the task already changed in fact.
You can see the task name here:
2.*:
NuGetCommand#2
Details link:
https://learn.microsoft.com/en-us/azure/devops/pipelines/tasks/package/nuget?view=azure-devops
0.*:
NuGetInstaller#0
Details link:
https://learn.microsoft.com/en-gb/previous-versions/azure/devops/pipelines/tasks/package/prev-versions/nuget-installer-0?view=tfs-2017
For the index of most DevOps built-in tasks:
https://learn.microsoft.com/en-us/azure/devops/pipelines/tasks/?view=azure-devops
For those backward compatible tasks：
https://learn.microsoft.com/en-gb/previous-versions/azure/devops/pipelines/tasks/?view=tfs-2017
The above resources should be enough.
So I'm currently trying to proceed through the release pipeline portion of an Azure DevOps Fundamentals for beginners course on Udemy, and the goal is to deploy the code for a small webapp game called "Flatris" for the purpose of showing how Azure works.
I've been following along with all the steps as per the course, but when I run the release pipeline build, it consistently fails with the message:
"Error: No package found with specified pattern: D:\a\r1\a***.zipCheck if the package mentioned in the task is published as an artifact in the build or a previous stage and downloaded in the current job."
So far, I've double checked the function of the Web App resource provided through Azure, it's showing traffic when I try and run the pipelines, so it's not the problem(i think), I've double checked the repositories, and they seem to be functioning well(i think), I'm unsure about the artifacts and whether that may be the source of the problem, but theres not enough specificity in the error logs for me to accurately isolate where the problem is.
I don't know if anyone else has managed to get pat this problem, or if it's unique to me with something I'm doing, but any help would be greatly appreciated.
Error: No package found with specified pattern: D:\a\r1\a***.zip
Check if the package mentioned in the task is published as an artifact in the build or a previous stage and downloaded in the current job."
When we use release pipeline for our application, we have to specify the artifacts that make up the application. And the artifact is a deployable component of your application. It is typically produced through a Continuous Integration or a build pipeline. Azure Pipelines releases can deploy artifacts that are produced by a wide range of artifact sources such as Azure Pipelines build, Jenkins, or Team City.
According to the error message, it seems you are using the build pipeline as artifact resource in the release pipeline.
To resolve this issue, we need make sure we have use the Publish build artifacts task to publish the artifacts to the Azure Pipelines in the build pipeline.
Then select the above build pipeline when we select the artifact source type:
In this case, Azure release pipeline will download the artifact automatically when we execute the release pipeline, the artifact will be save in the default folder D:\a\r1\a. That will resolve your issue.
I have a VSTS project and I'm setting up CI/CD at the moment. All fine, but I seem to have 2 options for the publishing step:
Option 1: it's a task as part of the CI Build, e.g. see build step 3 here:
https://medium.com/#flu.lund/setting-up-a-ci-pipeline-for-deploying-your-angular-application-to-azure-using-visual-studio-team-f686c8f190cf
Option 2: The build phase produces artifacts, and as part of a separate release phase these artifacts are published, see here:
https://learn.microsoft.com/en-us/vsts/build-release/actions/ci-cd-part-1?view=vsts
Both options seem well supported in the MS documentation, is one of these options better than the other? Or is it a case of pros & cons for each and it depends on circumstances, etc?
Thanks!
You should definitely use "Option 2". Your build should not make changes in your environments whatsoever, that is strictly what a "release" is. That link you have under "Option 1" is the wrong way to do it, a build should be just that, compiling code and making artifacts, not actually deploying code.
When you mesh build/releases together, you make it very difficult to debug build issues. Since your code is always being released, you really have to disable the "deploy" step to get any idea of what was built before you deployed.
Also, the nice thing about creating an artifact is you have a deployable package, and if in the future you need to rollback to a previous working version, you have that ready to go. Using the "build only" strategy, you'd have to revert your code or make unnecessary backups to achieve this.
I think you'll find any new Microsoft documentation pointing you toward this approach, and VSTS is completely set up like this. Even the "Configure Continuous Delivery in Azure..." feature in Visual Studio 2017 will create a build and a release.
Almost all build tasks are the same as release tasks, so you can deploy the app after building the project in build process.
Also there are many differences between release and build, for example, many environments, deployment group phase in release.
So which way is better is per to your detail requirement, for example, if build > deploy > other process is simple, you can do it just in build.
Regarding Publish artifact task, it is used to publish the files to VSTS server or other place (e.g. shared folder), which can be used in release as Artifact (Click Add artifact > Build in release definition), you also can download them for troubleshooting, for example, if you are using Hosted Agent that you can’t access, but you want to get some files (e.g. build result), you can add publish artifact task to publish to VSTS server, then download them (Open build result > Artifacts)
We have currently released our code to Production, and as a result have cut and branched to ensure we can support our current release, whilst still supporting hot-fixes without breaking the current release from any on-going development.
Here is our current structure:
Project-
/Development
/RC1
Until recently using Octopus we have had the following process:
Dev->Staging/Dev Test->UAT
Which works fine as we didn't have an actual release.
My question is how can Octopus support our new way of working?
Do we create a new/clone project in Octopus named RC1 and have CI from our RC1 branch into that? Then add/remove as appropriate as this RC's are no longer required?
Or is there another method that we've clearly missed out on?
It seems that most organisations that are striving for continuous something end up with a CI server and continuous deployment up to some manual sign off environment and then require continuous delivery to production. This generally leads to a branching strategy in order to isolate the release candidate to allow hot fixing.
I think a question like this raises more points for discussion, before trying to provide a one size fits all answer IMHO.
The kind of things that spring to mind are:
Do you have "source code" dependencies or binary ones for any shared components.
What level of integration / automated regression testing do you have.
Is your deployment orchestrated by TFS, or driven by a user in Octopus.
Is there a database as part of the application that needs consideration.
How is your application version numbering controlled.
What is your release cycle.
In the past where I've encountered this scenario, I would look towards a code promotion branching strategy which provides you with one branch to maintain in production - This has worked well where continuous deployment to production is not an option. You can find more branching strategies discussed on the ALM Rangers page on CodePlex
Developers / Testers can continually push code / features / bug fixes through staging / uat. At the point of release the Dev branch is merged to Release branch, which causes a release build and creates a nuget package. This should still be released to Octopus in exactly the same way, only it's a brand new release and not a promotion of a previous release. This would need to ensure that there is no clash on version numbering and so a strategy might be to have a difference in the major number - This would depend on your current setup. This does however, take an opinionated view that the deployment is orchestrated by the build server rather than Octopus Deploy. Primarily TeamCity / TFS calls out to the Ocotpus API, rather than a user choosing the build number in Octopus (we have been known to make mistakes)
ocoto.exe create-release --version GENERATED_BY_BUILD_SERVER
To me, the biggest question I ask clients is "What's the constraint that means you can't continuously deploy to production". Address that constraint (see theory of constraints) and you remove the need to work round an issue that needn't be there in the first place (not always that straight forward I know)
I would strongly advise that you don't clone projects in Octopus for different environments as it's counter intuitive. At the end of the day you're just telling Octopus to go and get this nuget package version for this app, and deploy it to this environment please. If you want to get the package from a different NuGet feed for release, then you could always make use of the custom binding on the NuGet field in Octopus and drive that by a scoped variable depending on the environment you're deploying to.
Step 1 - Setup two feeds
Step 2 - Scope some variables for those feeds
Step 3 - Consume the feed using a custom expression
I hope this helps
This is unfortunately something Octopus doesn't directly have - true support for branching (yet). It's on their roadmap for 3.1 under better branching support. They have been talking about this problem for some time now.
One idea that you mentioned would be to clone your project for each branch. You can do this under the "Settings" tab (on the right-hand side) in your project that you want to clone. This will allow you to duplicate your project and simply rename it to one of your branches - so one PreRelease or Release Candidate project and other is your mainline Dev (I would keep the same name of the project). I'm assuming you have everything in the same project group.
Alternatively you could just change your NuSpec files in your projects in different branches so that you could clearly see what's being deployed at the overview project page or on the dashboard. So for your RC branch, you could just add the suffix -release within the NuSpec in your RC branch which is legal (rules on Semantic Versioning talk about prereleases at rule #9). This way, you can use the same project but have different packages to deploy. If your targeted servers are the same, then this may be the "lighter" or simpler approach compared to cloning.
I blogged about how we do this here:
http://www.alexjamesbrown.com/blog/development/working-branch-deployments-tfs-octopus/
It's a bit of a hack, but in summary:
Create branch in TFS Create branch specific build definition
Create branch specific drop location for Octopack
Create branch specific Octopus Deployment Project (by cloning your ‘main’ deployment
Edit the newly cloned deployment, re-point the nuget feed location to your
branch specific output location, created in step 3