Microsoft is deprecating Windows Server 2016 DevOps agent in November 2021 and will remove it in March 2022.
We have started to get warnings about this on our releases, pushing us to migrate.
To prevent breakdowns in close future we would like to migrate ASAP but we have a large number of releases pipelines, so we would like to migrate agents on windows-latest as we do on build pipelines via YAML, mainly to not be bothered again about this.
However, this value doesn't seem to be available on release pipelines (despite being advised in the warning) :
What are we missing ? Thank you for your help !
I suppose what you are missing is thorough and complete documentation from Azure DevOps. No surprise there.
I re-read the docs in order to provide a response, and it appears the main issue is that Classic pipelines are not in full parity with YAML pipelines. Classic pipelines simply do not have the option to always use the latest available image.
One thing that is a bit of a tangent but could solve multiple problems in your case is to implement self hosted build agents. That will; 1. buy you more time to make sure your releases actually work on the latest image; 2. leave you in control of what image is on the agent(s) for longer than the Nov 15th cut-off.
Related
I am trying to find the most correct and simplest deployment process for each application release we have. The difficulties are the following:
It is Azure DevOps Releases.
Application has more than one artifact that should be delivered as a whole. Application distro, Its modules, and some configuration for servers that are not directly linked with the application, and of course automation scripts (which is versioned). All of them have their own build process and can be versioned separately.
All those components (App, separate server config, automation) are delivered as one product version. However, they could have different versions, for example: 12.2.1 (app), 12.2.3 (server), 12.2.1 (automation).
The question is how to build the process when after release (official), we can stick all of the final versions together (i mean not specifying them manually during pipeline release creation for each) taking into account that one of the component's version can be increased and we should be able to increase the version for release in terms of hotfixes for example.
Release Pipelines and 3 Artifacts: ok, there are 3 artifacts and a user has to specify all 3 versions manually during creation - quite a high risk to misclick. Unfortunately, there are 10 of them... 10 multiply 3 = 30 times to do a mistake.
Release Pipeline and 1 Artifact (app): Consider only one version of the application and automatically obtain automation scripts and configuration from feed by using app version. Could work, but no observability on what artifacts are going to be used, no way to downgrade, the only the latest version of artifacts (12.2.3.*).
Specify the version in the variable group connected to the stage (environments). Can easily make a mistake because release uses the baken version of the variable group. If you update VG, but not create a release - it will be epic fail. Moreover, there is no vision of what it is going to install/update, etc.
Please, share your ideas on how to manage multiple artifact versions within one product release to make the process more robust and clear with a little of flexibility.
That's how it works for me via this simple approach:-
A single build pipeline with many Agent Jobs where each one represents an artifact.
So here you will publish the different artifacts under separate folders and automatically increase versions "If needed", using a script per each and at the end all will be under the same BuildId.
Another variety if separation isn't needed that all be under the same Agent Job.
A single release pipeline that is linked to this big nested artifact that will perform the deploy.
Here also if separation is needed, could have multi stages or multi Agent Jobs as before.
Versions increasing either will happen manually at commits or scripts will automatically increase each build.
I would prefer the first as the 2nd doesn't indicate that there was any change.
The possibility of developer forgetting to update the version will be the same as developer introduces a bug so that can be fixed later.
Then at the end, you have a Single Release => Single Build => Many versions => A commit.
I have a software project which is currently hosted on BitBucket. I would like to implement a CI/CD pipeline which would have to run on local agents for build/test/deploy. The runners would also have to be compatibile with Windows 7/10 (x86/x64) and Linux (x86/x64/arm64/armv7). I am pretty new to DevOps, but after a thorough search, I came up with 2 options: GitHub and GitLab. Can you present to me which one would be better, exposing some advantages/disadvantages for each one? Thanks a lot
My recommendation would be you go with GitLab because of some of the following reasons.
GitLab CI has been in the market for a much longer time than GitHub actions that was announced in Nov of 2019 you can see some of the feature comparisons on GitLab blog here
When you are getting started It is much easier to navigate the GitLab GUI to configure all the tools that you need for DevOps in comparison to GitHub's somewhat difficult to navigate GUI due to the number of other tools that are available on GitHub
In addition GitLab is primarily focused on improving DevOps and as a result, they have integrated a couple of features over time in line with making the whole entire DevOps process much smoother than GitHub which just jumped started out in 2019.
Also there are a bunch of templates available for you to get started on GitLab which is not the case in GitHub.Plus these templates are in a wide range of languages which I am sure to cover your project requirements
Ease of access of CI within GitLab well in addition to having an easy to navigate GUI GitLab has all the tools necessary for your DevOps bundled in one location so every single DevOps feature that you will need will be accessible in this one place and in addition to that they do have a YAML template available for you that can help you get started quickly.
Finally there are way more features within GitLab majorly because it has been in the market since 2012 or 2011 compared to GitHub actions of 2019
There are however some major similarities that I would also like to point out which I believe could make your transition easier or just in case you want to try out both tools to judge for yourself.
Both GitHub Actions and GitLab Ci are build-in tools.
Both GitHub and GitLab use the same commands so there will not be a learning curve for you in terms of managing and collaborating changes on your project.
In Classic UI Release pipelines, you can specifiy pre-stage and post-stage Gates.
However using YAML releases, and projects Environments, you can only use the Approval & Checks feature on the Environment.
AFAIK this only behaves as an pre-deployment gate. Is there a way to perform a post-deployment check using YAML releases?
Sorry, it's not available right now. But there is a related feature request in our user voice site:
Add pre and post-deployment approvals for multi-stage pipelines (YAML), similar to release definitions
https://developercommunity.visualstudio.com/idea/567845/add-pre-and-post-deployment-approvals-for-multi-st.html
Kindly vote up and track the status on it. Our PM will also review it.
The company I work on recently purchased SonarQube Enterprise to improve code quality throughout all repositories. I found out that there is a feature that enables SonarQube to comment automatically on PRs targeting a specific branch, and I successfully managed to try that out.
Thing is:
That configuration is not scalable: I would need to manually configure every repo to follow that rule
That configuration needs a build pipeline to be defined "old school" on Azure DevOps to work, and we are moving into Pipeline as Code, starting of course with CI (where this takes place)
Anyone managed to get the PR commenting working in that scenario? Or, at least, solving the #1 problem?
Cheers
You can use REST APIs to do whatever configuration you need to do across your repositories. Refer to the REST API documentation.
Shouldn't matter, although I haven't tested it. The SonarQube tasks aren't aware of whether the build source is YAML or visual designer/classic/JSON builds. The underlying tasks and job running architecture is the same. As long as the build is hooked up to a branch policy, it should still work.
Azure DevOps Service has a version number, which we can see by browsing to https://dev.azure.com/my_organization/_home/about (see below).
My question is how is this version determined?
I guess that (in this example) 164 is the sprint number, and .1 is a build in the sprint.
However it's not clear what the "Dev18" stands for? How is it determined and when does it change?
I understand this question doesn't make much sense for SaaS, but in our case (regulated environment) it does.
As I know the Dev18 doesn't make much sense. Only the M164 matters in most cases, because sometimes we may need that to determine if you're in one region with the latest update.
And I just got some help from engineers who are more experienced in this topic and we can make the confirmation about the relationship:
Dev18<=>TFS 2020
Dev17<=>TFS 2019
Dev16<=>TFS 2018
Dev15<=>TFS 2017
Dev14<=>TFS 2015
So DavaShaw's guess is correct. It's the major version of TFS, so it won't be changed frequently. I think it will change only when a new TFS version is released. Hope it helps.
I'd guess the Dev18 is the major version of Azure DevOps Server that it is from.
Although, I can't be certain, some deduction leads me to believe it is...
VS and TFS Versions used to be in Sync:
TFS and VS 2015 - were 14.X
TFS and VS 2017 - were 15.X
But the cadence broke:
VS 2019 is now 16.X
Azure DevOps Server 2018 - would be also 16.X
Azure DevOps Server 2019 - would be 17.X
Azure DevOps is always ahead of what is in the Azure DevOps Server installations, so it seems reasonable to assume that the next release of Azure DevOps Server will be 18.X - probably called Server 2020.
All that said...
For Azure DevOps you should only be concerned with the Sprint Milestone that you are on
.