diff --git a/lib/bootleg/tasks/build/remote.exs b/lib/bootleg/tasks/build/remote.exs index 8761b80..41b693c 100644 --- a/lib/bootleg/tasks/build/remote.exs +++ b/lib/bootleg/tasks/build/remote.exs @@ -313,26 +313,25 @@ end task :clean_for_upgrade do remote :build do - "ls" - end - |> Enum.map( fn result -> - with {:ok, stdout_list, _code, _host} when stdout_list != [] <- result do - - locations = - stdout_list - |> Keyword.get(:stdout) - |> String.split("\n") - |> Enum.drop(-1) - |> Enum.filter(fn el -> el != "_build" end) - |> Enum.join(" ") - - if locations != "" do - remote :build do - "rm -rvf #{locations}" - end - end + "ls" + end + |> Enum.map(fn result -> + with {:ok, stdout_list, _code, _host} when stdout_list != [] <- result do + locations = + stdout_list + |> Keyword.get(:stdout) + |> String.split("\n") + |> Enum.drop(-1) + |> Enum.filter(fn el -> el != "_build" end) + |> Enum.join(" ") + + if locations != "" do + remote :build do + "rm -rvf #{locations}" + end end - end) + end + end) end task :generate_upgrade_release do @@ -359,7 +358,7 @@ task :remote_hot_upgrade do app_name = "#{Config.app()}" UI.info("Upgrading #{app_name} to version: #{Config.version()}") - + remote :app do "bin/#{app_name} upgrade #{Config.version()}" end diff --git a/lib/bootleg/tasks/deploy_upgrade.exs b/lib/bootleg/tasks/deploy_upgrade.exs index 0392da6..68c7193 100644 --- a/lib/bootleg/tasks/deploy_upgrade.exs +++ b/lib/bootleg/tasks/deploy_upgrade.exs @@ -48,5 +48,3 @@ task :unpack_release_upgrade do UI.info("Unpacked release upgrade archive") end - - diff --git a/lib/mix/tasks/upgrade.ex b/lib/mix/tasks/upgrade.ex index 232314f..1fff0e1 100644 --- a/lib/mix/tasks/upgrade.ex +++ b/lib/mix/tasks/upgrade.ex @@ -26,7 +26,7 @@ defmodule Mix.Tasks.Bootleg.Upgrade do the code of a running application without the need to stopping and restarting it, i.e. mantaining active the service in production. - + This is one of the most interesting capabilities of Erlang/OTP, but it is a very complex process that *cannot* be fully automated, i.e. require a good knowledge of the tecnologies @@ -60,24 +60,24 @@ defmodule Mix.Tasks.Bootleg.Upgrade do https://hexdocs.pm/distillery/guides/appups.html ### Bootleg hot upgrade task - + In the following description we assume that the development enviroinment is organized in this way (the build and the production places can be the same machine): - + * the development machine - where you edit and test locally your app source files; - + * the build machine - the computer where you will transfer to and compile the committed source code; - + * the production server - the server where you will deploy (transfer to and run) the code previously compiled on the build machine. - + Bootleg helps you in the hot upgrade process providing some specific tasks: - + * mix bootleg.build_upgrade will tranfer the last committed source code of your application from the development machine to the build directory of @@ -89,76 +89,76 @@ defmodule Mix.Tasks.Bootleg.Upgrade do you have to deploy your _first version_ of your app using `bootleg.build`, `bootleg.deploy` and `bootleg.start` (or `bootleg.update`); - + * mix bootleg.deploy_upgrade will transfer the tarball of the compiled app from the build machine to the production directory of the production machine, e.g. `~/production/myapp/` - + then will extract and setting up the needed files; - + * mix bootleg.hot_upgrade will call `mix distillery upgrade ` that will upgrade the running app to the last version. Notice that you *cannot* use this task if the app is not running, or if it there is a mismatch in the version numbers of the deployed versions. - + * mix bootleg.upgrade Call in sequences the above tasks in just one command. - + ### A step-by-step example - + Given you have configured the first version of your app with all the needed and appropriately customized Bootleg configuration files, you can go through the following steps to release and run the first version and subsequentely hot upgrade it to the newest versions: - + First version of your app: - + # Step 1 - deploy the first version of your app edit the version number of your in the mix.exs file (or in the file if you use an external reference), to the first version, e.g. 0.1.0; - + # Step 2 - Commit commit the changes you've made in step 1; - + # Step 3 - Build the first version use `mix bootleg.build` (not bootleg.build_upgrade!) to build your first version; - + # Step 4 - Deploy the first version use `mix bootleg.deploy` (not bootleg.build_upgrade!) to deploy your first version; - + # Step 5 - Run the first version use `mix bootleg.start` to run the app - + now your first version is up and running. To upgrade it to the future version, you have to follow these steps instead. - + Following versions: - + # Step 1 - update the version number e.g. 0.2.0 - + # Step 2 - Commit - + # Step 3 - Build the new version use `mix bootleg.build_upgrade` - + # Step 4 - Deploy the new version use `mix bootleg.deploy_upgrade` - + # Step 5 - Hot upgrade the new version use `mix bootleg.hot_upgrade` - + (or you can execute just the `bootleg.upgrade` that packs the previous tasks together if you don't need to manually adjust the created `appup` file) - + Now you have an upgraded version running. But if you stop and restart it, the previous version will be launched instead of the most recent. This is useful because if your new version