Usually when using capistrano, I will go and manually delete old releases from a deployed application. I understand that you can run cap deploy:cleanup but that still leaves 5 releases. Is this it's intended purpose? Is there another way to cleanup old releases to just 1 previous deploy?
You can use the :keep_releases variable to override the default of 5. Check this out.
You could do this automatically by setting this in your deploy.rb
set :keep_releases, 1
after "deploy:update", "deploy:cleanup"
In the past(I don't know exactly which version) this callback was the default, but later the developer decided to leave it to the user to decide. In capistrano 3 it was added back to the default deploy flow.
If you want to delete all releases except the last 3 for example you can run:
cap deploy:cleanup -s keep_releases=3
I had a similar problem. I wanted to keep the 5 releases for normal deployments but needed for certain situations to be able to remove all previous releases.
I was able to do this with a custom task. Create a file lib/capistrano/tasks/cleanup.rake and add the following code.
desc "Remove all but the last release"
task :cleanup_all do
set :keep_releases, 1
invoke "deploy:cleanup"
end
To run use bundle exec cap staging cleanup_all or cap staging cleanup_all
Related
I'm trying to setup a release to three environments, Dev, QA, Production, and working through failures, mainly IIS Application errors.
Right now, I'm trying to get my QA environment setup. Unfortunately it is a lot of trial and error to get the release to pass. When it fails, I have to go edit the release, edit my tasks for the QA environment, then start a release all over.
My problem is, I'm just trying to get this setup, these aren't "real" releases. However I'm wasting time after each configuration change having it deploy code to my "Dev" environment. I already know those steps work.
Is there a way I can skip an environment, and select a specific environment I want it to release code too?
As Daniel said that you can choose the environments which you want to deploy manually when start a release.
You also can set Manual only for the environment directly:
You also can enable Artifact filters with specific tags or branch (git), then just the artifact meet the filters, the release can deploy to this environment.
When you start a release you're presented with a list of all of the environments and their deployment conditions. Simple set all of the environments to "Manual". Then when you create the release, you can choose the environment to which you wish to deploy from the "Deploy" menu.
We are using octopus to deploy our project. A bunch of steps which gets executed during the deployment. One of them is a powershell script and that powershell script is a work in progress.
However to test the script we have to perform a dummy check in or can create a new release in octopus after we change the build powershell script step, and it will pick up the build steps straight away and does not cache, else the script which gets executed is the previous version.
I do not know if this is caching or some other issue. I think this is some kind of issue with octopus or setting which I am missing.
Please help.
An important aspect of deployment automation is ensuring that deployments are repeated exactly each time they run.
When you create a release in Octopus Deploy, the artefacts, process, and variables are all "locked in" for that release. This means no matter what changes you make, for the lifetime of that release it will be performed identically every time.
If your deployment tool didn't do this, the same relase could work in your test environment, but then fail in the live environment because the deployment process changed in some way.
In effect, you release changes to the deployment process in the same way you release changes to the application itself.
This is why you need to create a new release in Octopus Deploy in order to see the changes you make.
This is both a blessing and a curse... On the one hand - your existing release scheduled for Production is protected from changes being made in lower environments. On the other hand - you are forced to recreate a release if you need to make a slight process change mid-cycle. This is arguable the correct approach since you would want to test any changes - but maybe not relevant if your changes can only be tested in higher environments (e.g maybe only Production is load balanced).
The software does allow to update Variables mid-cycle, but not Process Steps. I believe this feature is been requested for a future release.
http://help.octopusdeploy.com/discussions/questions/5130-how-to-update-a-single-variable-in-an-existing-release
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.
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.
I tried using "cap rollback" but I get the following error:
$ cap rollback
the task `rollback' does not exist
Is there some additional setup that I need to do to get rollbacks to work?
Just found the answer here http://github.com/leehambley/railsless-deploy:
cap deploy:rollback
If you're using different environments (e.g. staging, production) using the multistage gem (e.g. you have require 'capistrano/ext/multistage' in your deploy.rb file) then Capistrano defaults to staging. So, to roll back a production environment you would do:
cap production deploy:rollback
and, assuming you've got the defaults set, this would roll back staging:
cap deploy:rollback
Worth knowing if you're using different environments and wondering why it's not working for production.
simple roll back:
$ cap deploy:rollback
rollback to specific version:
$ cap deploy:rollback -s previous_release= [path to previous release under releases folder ]
Actually it is
cap deploy:rollback:code
deploy:rollback may rollback to a previous revision, not necessarily a previously deployed revision.