I want to add Build and Release pipelines in Azure Devops for my .Net Core application. Application uses EF Core migrations.
I used the solution provided for example here: https://blog.clear-measure.com/2019/01/07/run-ef-core-migrations-in-azure-devops/
It works fine. I generate script during build, publish it as another artifact and then use it to run against database during release step.
But how to deal with a situation that I want to revert the changes. Here I see two scenerios:
It would be great if somehow I could just click Deploy on the previous release and this way get back to the previous working version of the app (and revert the DB as well).
Revert the changes in the repo, deleting migrations that might have been created between releases and start build and deploy process again. How to revert already added migration to the DB?
Is even the first approach possible ?
Thanks for you help!
You would revert the migration via EF Core similar to the way you add a migration. Then commit and push and run the pipeline.
https://learn.microsoft.com/en-us/ef/core/managing-schemas/migrations/#revert-a-migration
First scenario is possible.
In your release pipeline, you can find the retained historical releases.
Select the previous release you want to revert back to, click redeploy and it will roll back to the previous version.
Related
I have a build done for a ASP.Net project.
In code I have updated the names of several fields in an HTML but, when the build is launched and published, it never updates the changes I have made.
It always takes the original version to create the artifact.
I have deleted and created the build from scratch, but it always does the same thing.
What can I do?
I have more builds just like this one and this doesn't happen.
Best regards,
Have you checked the commit version of your pipeline?
It may due to your pipeline using another branch, which is the original version.
Our team had to test something in an older release. I went to the Release that was needed to be redeployed. We only needed one App to be redeployed, so I went inside the older release from the list and clicked "Redeploy" to that one particular stage.
When the deployment were done, I found that it actually deployed the latest changes. Am I using an incorrect method to redeploy an older release to only one stage? Should I create a brand new release pointing to older artifacts instead?
This is just opinion, but I think that better apporach is to create a new release pointing to older artfact. Why? Because you have clear perspective what was deplyed and what is currently available. Otherwise, you may get false perspective.
When we deploy to our Testing environment with Sqitch, the migrations run and all is well. However, when we have to test a different code branch, the Sqitch migrations aren't rolled back. What I'm looking for is an idea of how others are solving this problem. For example, if I have a migration that creates a table my_table, and then deploy a migration from a different branch, Sqitch gets too confused to move forward.
Reason for branch change: we have features using our develop branch, and hotfixes being applied to master (I know; we're going to change that). Swapping over to test a hotfix caused all of this mess.
We considered having a Jenkins job to run a sqitch revert and have the user supply the migration to roll back to, but we want to eliminate the manual step.
How do you manage migrations when having to switch code branches?
I believe this is the purpose of sqitch-checkout
I have a release definition,now I want to take the backup of old one before deploying new one if any know the answer please share the steps or picture
Because I'm new to CI/cd
According to your description, seems you want Azure DevOps for a release definition to have a step that backs up the directory for the application before it deploys the updated code.
There are a Copy Files and a Archive Files task which you can drop into your process. You can even make the tasks conditional based on your needs.
When you want the "old" release, the normal thing to do would be to schedule a new release with the previous version to install. Or to fix the issue and trigger a new release with the fixed contents.
I'm trying to set up a deployment in Octopus Deploy. As many other devs, I do that through iterations: tweak steps/scripts/packages -> click "Deploy" -> inspect the outcome -> start again if not satisfied. In case of Octopus Deploy, it uses a snapshot of the deployment process if any steps/scripts were changed since last release. Basically, when it comes to deploy, I get this warning:
Warning: for consistency, this deployment will use a snapshot of the variables and deployment process, which do not include the latest changes that have been made to the project. A changed process can only be incorporated by creating a new release (this one may be renamed if desired). Variables can be updated via the release page.
This means that I need to add a new release just to check if my deployment scripts change has taken effect or not. To add a release, I need to update the version and so on.
My question would be: how can I redeploy the same release with all the step changes introduced since the previous release? Is there a way to not create a new release to do that?
I asked this question of Paul Stovall several months ago when I started working with Octopus. His answer was "no".
I'm afraid there is not a way to do this without creating a new release. When you create a release, Octopus deploy stores an object in its internal database which is a snapshot in time containing everything needed to deploy. It doesn't have a mechanism to update these stored objects, and so it is required for you to create a new release each time.
Please note that even though a snapshot of the process is taken, the variables can be updated if you're redeploying a previous release. If you're just changing variable values, then yes, you can reuse the same release over and over. If you're changing any of the process steps, then no - you have to create a new release.
If anything the version number just helps keep things segregated. The only time this becomes a problem is if you're using NuGet versioning, but if you're using the standard variable template versioning in Octopus deploy, it's incrementing the last digit in the version number.
You can rename your failing release on the release page (under: Edit this release). That way you can create a new release with the old versionnumber and avoid unecessary work.