We're putting together our CI pipelines and a need we'll quickly have is the ability to visualize all pipelines, at the very least determine which ones are waiting for input.
Our general flow is very roughly:
Deploy to dev
Prompt QA team for QA deployment approval
Deploy to QA
Prompt QA team for Staging environment deployment approval
Deploy to Staging
QA Signoff
Business Signoff
Deploy to prod
With some smoke test steps in the way. Would love for the QA team to have a dashboard of which pipelines are awaiting their approval.
Even a view that shows the last invocation of every pipeline would be sufficient (you could at least quickly see which stage certain jobs are paused at - we will use the same pipeline design for most of our microservices)
Anything out there that would be useful for us?
This is definitely for you. I have been using this for around 6 Months now .
Hygieia Dashboard
You can use AnyStatus which is a desktop application for Windows that brings together metrics and events from various sources such as Jenkins, Azure DevOps, TeamCity and more. AnyStatus supports Jenkins Jobs and Views. It can also monitor other resources such as web servers, databases, operating system metrics and others.
Disclaimer: I am the author of AnyStatus.
Related
We have been converting our Release pipelines in Azure DevOps to instead be YAML files that run as Pipelines. This is so we can store our deployment process as code. The deployment process is working well - so a developer commits code and the Pipeline builds and publishes the artifact in one stage and then it auto-deploys to the QA environment in another stage. Subsequent stages deploy to an Environment (e.g. QA, Staging, Production) each of which requires some approval(s). The deployments themselves aren't the issue.
What I'm struggling with is unlike the old Releases there isn't a dashboard that will tell me which version of the project is in each environment. The Pipeline summary represents each stage for the Run as a dot (running, succeeded, failed, canceled, etc.) but wasn't built to represent what each environment has (probably because a stage doesn't have to be a deployment).
Is there somewhere else I can look for this information or do I have to build my own dashboard by calling the AzDO APIs? Looking at the Environment gives a list and I can root through the history, but that's not the experience our developers are looking for.
Traditionally we have to deliver our applications on the test and pre-production platforms one by one (usually by hand using setups). Applications like the front end javascript SPA UI are linked to backend services and their delivery sometimes goes together.
Each service and each application has its own git repository. (we are using on premise TFS 2018 for now )
Then when it is necessary to go into production, we deliver all of the front end services and applications at once that have been validated at once.
We would like to automate our process but we don't know if Azure Devops is suitable.
From what I understand with Azure Devops, we can make an independent artifact for each microservice and each front end application. We can also deliver them independently.
It seems to me that Azure Devops by default allows you to manage the delivery cycle for a particular microservice but not for an assembly making up a complete system, right?
But is it possible to deliver a set of projects each with a particular version? For that, must all of our projects be in the same solution or the same git repository?
Yes, you can use multiple artifacts from different sources (build artifacts, repositories, package feeds, github, docker hub, Azure Container Registry, ++) within a single pipeline or release definition. That's true for both the classic release definitions and the modern multi-stage pipeline implementation.
For example you can define a pipeline or release definition that consumes a front-end web app from a build artifact sourced from RepoA, a back-end service artifact consumed from a container registry originally from RepoB, and say a script library in the form of a Git artifact from RepoC. From there you could deploy each of those artifacts together, or in parallel stages, in sequence, partially, with approvals, conditionally, etc, all from the same pipeline.
The full configuration as code YAML multi-stage pipelines are still in preview, so there are some workflow orchestrations that are a little tougher to implement. But there is enough feature parity with the classic release definitions that I would default to using multi-stage for any net new needs.
I'm trying to configure Azure DevOps Release pipelines for our projects, and I have a pretty clear picture of what I want to achieve, but I'm only getting almost all the way there.
Here's what I'd like:
The build pipeline for each respective project outputs, as artifacts, all the things needed to deploy that version into any environment.
The release pipeline automatically deploys to the first environment ("dev" in our case) on each successful build, including PR builds.
For each successive environment, the release must have been deployed successfully to all previous environments. In other words, in order to deploy to the second environment ("st") it must have been deployed to the first one ("dev"), and in order to deploy to the third ("at") it must have been successfully deployed to all previous (both "dev" and "st"), etc.
All environments can have specific requirements on from what branches deployable artifacts must have been built; e.g. only artifacts built from master can be deployed to "at" and "prod".
Each successive deploy to any environment after the first one is triggered manually, by someone on a list of approvers. The list of approvers differs between environments.
The only way I've found to sort-of get all of the above working at the same time, is to automatically trigger the next environment after a successful deployment, and add a pre-deployment gate with a manual approval step. This works, except the manual approval doesn't trigger the deployment per se, but rather let an already triggered deployment start executing. This means that any release that's not approved for lifting into the next environment, is left hanging until manually dismissed.
I can avoid that by having a manual trigger instead of automatic, but then I can't enforce the flow from one environment to the next (it's e.g. possible to deploy to "prod" without waiting for successful deployments to the previous stages).
Is there any way to configure Azure DevOps Release Pipelines to do all of the things I've outlined above at once?
I think you are correct, you can only achieve that by setting automatic releases after successful release with approval gates. I dont see any other options with currect Azure DevOps capabilities.
Manual with approval gates doesnt check previous environments were successfully deployed to, unfortunately.
I hope this provides some clarity after the fact. Have you looked at YAML Pipelines In this you can specify the conditions on each stage
The stages can then have approvals on them as well.
It makes sense to have a pre deployment approval for an environment but what is a post deployment approval and why might I use it? No definition in Team Service docs here
Validating testing is the main scenario I can think of. Imagine a deployment chain that goes
Dev -> Test -> UAT -> Prod
So I set up a trigger to deploy to dev on every check-in / commit and run some basic smoke tests.
Then I set up a scheduled deployment to Test for 3AM and run a more comprehensive set of automated tests, however certain bits of the application still rely on manual testing. The testers can approve or reject the release post deployment based on if they find any bugs. If the testers (or test lead) don't approve the post deployment step then the release cannot proceed to UAT.
You then might have Business Users who approve deployment to UAT and once testing is complete validate that the release can go live. (Another post deployment check)
Finally you might have a check that approves deployment to production.
If you have 100% automated testing in all environments then you don't need these kind of manual interventions, however if you still need manual testing then this can prove a fairly light weight way of ensuring a sensible approvals process is in place.
Different groups sometimes "own" different environments, so they control when things deploy to their environments and when things are ready to leave their environments. The scenario I commonly use to explain this is as follows:
You have a dev server that's owned by developers. Changes get pushed there and signed off on by a dev team lead. The dev team lead does a post-deployment approval for the "Dev" environment.
Then it goes off to the QA environment. The QA team might be in the middle of some manual testing of the previous build. They want to conclude that before the next build comes their way, so the QA team lead get a pre-deployment approval. The devs might sign off on 10 releases in the interim, but the QA team lead can choose just to take the most recent one, since testing older builds isn't doing anyone any good.
Then, the QA team signs off and it goes to a UAT environment. UAT is owned by the product owner, who frequently demos the upcoming changes to upper management and/or end-users. The product owner will want to control when a UAT deployment happens, because they don't want their demo to get ruined by an inopportune deployment. Without a post-deployment approval owned by the QA team, the product owner might take an untested, unvalidated build and deploy it and end up demoing something horribly broken, making everyone look bad.
And so on.
How would one go about creating a secure means of deploying a package by way of Octopus Deploy?
Implementing a duplicate team, former for developers to deploy to development environment, the latter, to deploy to staging/production environment, with identical roles and specific users that would be team leads that can only deploy to staging/production.
The idea is to prevent developers from having to deploy or promote to staging/production as means of security.
It seems rather clunky in having a duplicate team, and would cause confusion especially when new octopus projects are created in the regards of syncing up between the duplicate teams.
What would you advise/recommend in this approach?
Ninja Edit I have included the tags teamcity and powershell as that is the idea - teamcity, when a build process is kicked off, that will deploy a build eventually leading to octopus deploy which will carry out the deployment process to that environment.
We're in a similar situation where developers are responsible for the DEVELOPMENT environment, testers for TEST and the operations team for PREPROD and PROD.
This is enforced by providing all users with access to Octopus Deploy, creating environment specific teams with roles scoped to particular environments; and assigning users to teams.
http://docs.octopusdeploy.com/display/OD/Managing+users+and+teams