I want to create rollback task for Release Management in visual basic online.
i have some steps but it will take more time.
steps are:
Back Up: perform a backup of the original files to use for rollback later.
Deploy:Copy latest files from artifact to the target folder.
3.Configure — Make configuration changes to the setup.
4.Rollback — Rollback the files from backup in case Deploy failed. Delete backup before exiting.
we can see it will take long time while backup a database . So how we can optimize ?
is there any other method so we can implement and take less time when we will do rollback task ?
There isn’t the built-in feature/task to rollback changes in release, you need to do it by your own script.
There are various options that can be considered as a rollback
strategy.
Option#1 : Undo the change by redeploying the previous release
The first option is to simply redeploy the previously successful
release. This might work well for standalone applications.
Whenever an application depends on some external services or has a
database involved, this approach does not work well. The dependent
services might have upgraded and no longer compatible with the
previous release. The database might have changed the schema making
the previous release no longer healthy.
Option#2 : Fix the issue, do another release
The second option is to simply do nothing. Something went wrong,
troubleshoot it and fix it. Once we fix the issue, we can do another
release.
This however means the environment would remain unhealthy for some
time, as long as it takes for the fix to be ready and deployed.
Option#3 : Understand what failed in the deployment and make a temporary change for the time being
Both the above options are both valid approaches but with some
limitations.
That brings us to a third option. While the fix is getting ready
(option 2), make a minimum change to the environment to get it
temporarily healthy.
More information, please refer to: Implement Rollback with Release Management for TFS 2015 (Apply to VSTS)
You can't really optimise the backup/restore process.
If you use a Virtual Machene to deploy to then you should snapshot it prior to the upgrade, then a roll back is simply restoring the snapshot.
This will be much quicker, seconds, rather than minutes or hours...
Related
We are planning to migrate over from TFS 2015 to Azure DevOps, and the task assigned to me is to find out the way to do a comparison after the migration between what we have on TFS and Azure to ensure that all the tasks, bugs, etc was successfully migrated over. I've checked with the Guide from Azure and found nothing about such post migration checking and comparison. Is there any tool for this or we can only do the whole checking and comparison manually?
There is no such tool.
I have never experienced a partial migration. Due to the way the import works that is also VERY unlikely. Either the complete import fails, or the data is going to be there. I've done many of these migrations as well as server migrations/upgrades and the kind of data-loss you're worried about has never happened.
The one thing you'd need to be careful of are the changes to the retention policies.
We've been using Gitlab on my current job for a while now, and have encountered some instability which express itself in various ways.
The most recent one: projects that should be deleted are flagged as such but actual deletion never occurs.
Some research has allowed me to see the probable cause of the problem, but not how to resolve it: the ProjectDestroyWorker hasn't run for over 10 days.
Could someone point me to some documentation on the mechanism(s) that trigger the workers, and how to monitor them?
Version: GitLab Community Edition 8.5.0 a513e09
You have a few issues with this kind of problem: issue 15334, issue 20984.
Checking the backtrace from sidekiq.log can help
Merge Requests 5695 and 4341 (for GitLab 8.11) should fix some of those issues, like:
There is a race condition in DestroyGroupService now that projects are deleted asynchronously:
User attempts to delete group
DestroyGroupService iterates through all projects and schedules a Sidekiq job to delete each Project
DestroyGroupService destroys the Group, leaving all its projects without a namespace
Projects::DestroyService runs later but the can? (current_user, :remove_project) is false because the user no longer has permission to destroy projects with no namespace.
This leaves the project in pending_delete state with no namespace/group.
I came across this issue during the migration to hashed storage in v13.5.7
Drop to the ruby console & destroy projects that are pending
deletion
In my particular case this allowed gitlab-rake gitlab:storage:legacy_projects to correctly show 0 so further upgrades were possible.
I've recently been on a support ticket with Azure, and they've recommended turning on Local caching to eliminate occasional outage blips.
The problem with that, is that you need to watch your disk space, since >1Gig is not allowed. And if you deploy from git, like I do, that's an issue because the whole repository is checked out, then built locally, and then kudu-synced.
I've looked at trimming my repo down, but that's only going to yield small savings. What I'd like to do is to remove my repository folder once the deployment has complete. Is that a sensible idea, or are there other solutions to this problem?
There is an upcoming change to the Local Caching behavior that will make it skip the repository folder (since it's not needed at runtime). This should be in the next couple of weeks.
Once that change is out, this issue should automatically go away for you.
the repository folder only container a copy of your repo. it is ok to remove it if you want to safe some space. it will be re-create when there is a new deployment.
There is one side effect when you delete your repository folder, your next deployment will take longer time since it will need to sync your entire repository.
Other than repository folder, you can cleanup files that under D:\home\LogFiles as well, to safe you some more spaces
I would recommend you to use build sequence using Visual Studio Team Services - there, you can do anything you want and include operations into the build pipeline (build trigger => delete the folder).
Is there a way to rollback a Windows Azure Website and SQL deployment / publishing?
I published a website, now it's causing a lot of errors, and I want to get back to the previous state and work on the code some more.
Is this possible?
If you use Git or TFS you can take advantage of deployment rollback by selecting the previous deployment (as explained by Nathan Totten):
To rollback the database you can do several things. The easiest could be to use EF Migrations:
Run EF Migrations from your Application_Start (not sure if this is something you want to do
(Manually) call migrations.exe:
Migrate.exe MyApp.exe /startupConfigurationFile=”MyApp.exe.config” /targetMigration=”MyPreviousVersion”
I've been doing some research into finally automating our Development builds and still have one nagging question that I'm hoping the StackOverflow community can solve for me.
My understanding is that an IntervalTrigger when setup properly will check VSS every X seconds for changes and if it finds a modified file, will run my tasks. One of my tasks would be to checkout the AssemblyInfo files and update the version numbers. After these files are updated they would be checked back into VSS.
Thinking about this solution it doesn't make much sense because in my mind, I'm forcing the check for changed files to true every time the trigger fires. Am I missing something here? Is there a way of doing this without triggering an automatic build on the AssemblyInfo check-in?
You can use a Filtered Source Control Block to exclude certain files from the trigger.
I just posted a bunch about my default build process here which may be of some interest to you: SVN Website Development and Deployment Solution
The way I usually configure my projects with CC.NET is to have two project blocks per solution. One configured as an interval trigger that does nothing more than get the latest from my repository, build the solution, and run unit tests. The other is a schedule trigger that does all the things the other one does, but actually publishes a build. This includes changing version numbers, publishing files, etc. This might work in your case, since the change in version would cause the interval project to trigger, but only once.
Checking the automatically generated AssemblyInfo into the version control system is a bad idea, don't do it. You'll get a lot of noise (50% of all commits!) in your history. Also, it does not give you any new information - you can always pull this from VCS. Have your build script autogenerate those files is a good practice, but don't push those changes back!