Since my project is still just in development, when making my builds, I always push and replace a single docker image in ACR with the :latest tag. My app is in 'Multiple' revision mode and my build script creates a new revision based on the latest as a template.
Now, I had a persistent provisioning failure, so I attempted to activate my latest successfully provisioned revision, but it still failed with the same error.
Does each revision need to be created with it's own separate source image, in order for me to be able to return to a previous build if my current one fails? What is the safest approach for production?
Does each revision need to be created with it's own separate source image, in order for me to be able to return to a previous build if my current one fails? What is the safest approach for production?
Yes, the image isn't copied. It'll be pulled from your registry every time the revision is activated or scales out or moves between VMs.
You can use a git commit id or a build version for the image tag.
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.
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 have a project hosted on GitHub and I have it compiling with Appveyor.
I would like to set up Appveyor so that each build is deployed as a GitHub release, but with each build overwriting the last. This way there will only be one GitHub release from Appveyor that will always have the latest build attached.
I can't see how to do this, because if I specify a release in appveyor.yml I get an error saying the release already exists (yes I want to overwrite it), and if I don't, then each deployment creates a new tag with the current build, which will litter the repository with useless tags.
On top of that, every time the release gets deployed, it creates a new tag which in turn triggers another Appveyor build. This means every push to the repository triggers two identical builds.
Has anyone worked out a way to deploy to the same GitHub release continuously, replacing the files with the latest versions, and to prevent a new Appveyor build from being triggered in response to an Appveyor deployment?
You can add force_update: true to GitHub deployment provider settings to overwrite existing release.
I use Bamboo CI to manage my git repo for Salesforce development. It runs my tests after each commit and if successful, then deploys to an org. This all works wonderfully except for when I've deleted files, because Salesforce needs a special xml built-up in order to remove them from the org. So I have added a step to my build process that will diff the repo (from previous successful build to HEAD), extract a list of any files which have been removed from git since the last build, and parse that information info into the appropriate xml format.
The Question: What I need now is a way to set up the deployment job such that it will be able to tell me the revision number of the previous successful deployment. Is there a way to have a script task set a value on a Bamboo global variable? If so, maybe I could just have a task which runs at the end of deployment record the current revision number and have it available to the next job?
Note: The deployments only run after builds are stable, meaning that there might be many commits (and builds) between last run and current run. Bamboo does provide a system variable for current revision number ($Bamboo.planRepository.revision) but the analogous system variable for previous revision number ($Bamboo.planRepository.previousRevision) is available in build environments only, with no such luck for deployment environments.
I am using a build definition that makes use of LabDefaultTemplate.11.xaml for deploying the builds. In the lab process settings i have selected "Latest" under 'Select an existing build' in the Build tab. Ideally it should always pickup the latest available build to deploy BUT instead it is picking some old build which was created few days back. The only difference in the old build and the recent builds is that it passed successfully when it was created whereas the recent builds have partially succeeded.
What might be the problem and possible solution? Quick reply would be appreciated.
Thanks,
-w
Latest in that drop down means it will pick up the Latest successful build. It is working as designed.
If you want to change the logic you'll have to edit the XAML workflow and possibly write a custom activity.