Skip to content

Commit 725ad89

Browse files
guidotripaldiguidotripaldi
committed
Changes the heredoc identation
1 parent d6c3653 commit 725ad89

File tree

1 file changed

+110
-110
lines changed

1 file changed

+110
-110
lines changed

‎lib/mix/tasks/upgrade.ex

+110-110
Original file line numberDiff line numberDiff line change
@@ -59,117 +59,117 @@ defmodule Mix.Tasks.Bootleg.Upgrade do
5959
# Distillery - Appups
6060
https://hexdocs.pm/distillery/guides/appups.html
6161
62-
### Bootleg hot upgrade task
63-
64-
In the following description we assume that the development
65-
enviroinment is organized in this way (the build and
66-
the production places can be the same machine):
67-
68-
* the development machine - where you edit and
69-
test locally your app source files;
70-
71-
* the build machine - the computer where you will transfer to
72-
and compile the committed source code;
73-
74-
* the production server - the server where you will deploy
75-
(transfer to and run) the code previously compiled on
76-
the build machine.
77-
78-
Bootleg helps you in the hot upgrade process providing
79-
some specific tasks:
80-
81-
* mix bootleg.build_upgrade
82-
will tranfer the last committed source code of your application
83-
from the development machine to the build directory of
84-
your build machine, for example `~/build/myapp/`, then
85-
it will clean the directory from the previous code deleting
86-
every file but the `_buil` directory, it will generate the
87-
`appup` file and compile the newest app release.
88-
Please note th before you can use this task for the first time,
89-
you have to deploy your _first version_ of your app using
90-
`bootleg.build`, `bootleg.deploy` and `bootleg.start`
91-
(or `bootleg.update`);
92-
93-
* mix bootleg.deploy_upgrade
94-
will transfer the tarball of the compiled app from the
95-
build machine to the production directory of the production
96-
machine, e.g. `~/production/myapp/`
97-
98-
then will extract and setting up the needed files;
99-
100-
* mix bootleg.hot_upgrade
101-
will call `mix distillery <myapp> upgrade <version>` that
102-
will upgrade the running app to the last version. Notice that
103-
you *cannot* use this task if the app is not running, or
104-
if it there is a mismatch in the version numbers of the
105-
deployed versions.
106-
107-
* mix bootleg.upgrade
108-
Call in sequences the above tasks in just one command.
109-
110-
### A step-by-step example
111-
112-
Given you have configured the first version of your app with all
113-
the needed and appropriately customized Bootleg configuration files,
114-
you can go through the following steps to release and run the
115-
first version and subsequentely hot upgrade it to the newest
116-
versions:
117-
118-
First version of your app:
119-
120-
# Step 1 - deploy the first version of your app
121-
edit the version number of your in the mix.exs file
122-
(or in the file if you use an external reference),
123-
to the first version, e.g. 0.1.0;
124-
125-
# Step 2 - Commit
126-
commit the changes you've made in step 1;
127-
128-
# Step 3 - Build the first version
129-
use `mix bootleg.build` (not bootleg.build_upgrade!) to build
130-
your first version;
131-
132-
# Step 4 - Deploy the first version
133-
use `mix bootleg.deploy` (not bootleg.build_upgrade!) to deploy
134-
your first version;
135-
136-
# Step 5 - Run the first version
137-
use `mix bootleg.start` to run the app
138-
139-
now your first version is up and running. To upgrade it
140-
to the future version, you have to follow these steps instead.
141-
142-
Following versions:
143-
144-
# Step 1 - update the version number
145-
e.g. 0.2.0
146-
147-
# Step 2 - Commit
148-
149-
# Step 3 - Build the new version
150-
use `mix bootleg.build_upgrade`
151-
152-
# Step 4 - Deploy the new version
153-
use `mix bootleg.deploy_upgrade`
154-
155-
# Step 5 - Hot upgrade the new version
156-
use `mix bootleg.hot_upgrade`
157-
158-
(or you can execute just the `bootleg.upgrade`
159-
that packs the previous tasks together if you don't need to
160-
manually adjust the created `appup` file)
161-
162-
Now you have an upgraded version running. But if you stop
163-
and restart it, the previous version will be launched instead
164-
of the most recent. This is useful because if your new version
165-
has some blocking bug, you can easily restart the service to the last
166-
working release.
62+
### Bootleg hot upgrade task
63+
64+
In the following description we assume that the development
65+
enviroinment is organized in this way (the build and
66+
the production places can be the same machine):
67+
68+
* the development machine - where you edit and
69+
test locally your app source files;
70+
71+
* the build machine - the computer where you will transfer to
72+
and compile the committed source code;
73+
74+
* the production server - the server where you will deploy
75+
(transfer to and run) the code previously compiled on
76+
the build machine.
77+
78+
Bootleg helps you in the hot upgrade process providing
79+
some specific tasks:
80+
81+
* mix bootleg.build_upgrade
82+
will tranfer the last committed source code of your application
83+
from the development machine to the build directory of
84+
your build machine, for example `~/build/myapp/`, then
85+
it will clean the directory from the previous code deleting
86+
every file but the `_buil` directory, it will generate the
87+
`appup` file and compile the newest app release.
88+
Please note th before you can use this task for the first time,
89+
you have to deploy your _first version_ of your app using
90+
`bootleg.build`, `bootleg.deploy` and `bootleg.start`
91+
(or `bootleg.update`);
92+
93+
* mix bootleg.deploy_upgrade
94+
will transfer the tarball of the compiled app from the
95+
build machine to the production directory of the production
96+
machine, e.g. `~/production/myapp/`
97+
98+
then will extract and setting up the needed files;
99+
100+
* mix bootleg.hot_upgrade
101+
will call `mix distillery <myapp> upgrade <version>` that
102+
will upgrade the running app to the last version. Notice that
103+
you *cannot* use this task if the app is not running, or
104+
if it there is a mismatch in the version numbers of the
105+
deployed versions.
106+
107+
* mix bootleg.upgrade
108+
Call in sequences the above tasks in just one command.
109+
110+
### A step-by-step example
111+
112+
Given you have configured the first version of your app with all
113+
the needed and appropriately customized Bootleg configuration files,
114+
you can go through the following steps to release and run the
115+
first version and subsequentely hot upgrade it to the newest
116+
versions:
117+
118+
First version of your app:
119+
120+
# Step 1 - deploy the first version of your app
121+
edit the version number of your in the mix.exs file
122+
(or in the file if you use an external reference),
123+
to the first version, e.g. 0.1.0;
124+
125+
# Step 2 - Commit
126+
commit the changes you've made in step 1;
127+
128+
# Step 3 - Build the first version
129+
use `mix bootleg.build` (not bootleg.build_upgrade!) to build
130+
your first version;
131+
132+
# Step 4 - Deploy the first version
133+
use `mix bootleg.deploy` (not bootleg.build_upgrade!) to deploy
134+
your first version;
135+
136+
# Step 5 - Run the first version
137+
use `mix bootleg.start` to run the app
138+
139+
now your first version is up and running. To upgrade it
140+
to the future version, you have to follow these steps instead.
141+
142+
Following versions:
143+
144+
# Step 1 - update the version number
145+
e.g. 0.2.0
146+
147+
# Step 2 - Commit
148+
149+
# Step 3 - Build the new version
150+
use `mix bootleg.build_upgrade`
151+
152+
# Step 4 - Deploy the new version
153+
use `mix bootleg.deploy_upgrade`
154+
155+
# Step 5 - Hot upgrade the new version
156+
use `mix bootleg.hot_upgrade`
157+
158+
(or you can execute just the `bootleg.upgrade`
159+
that packs the previous tasks together if you don't need to
160+
manually adjust the created `appup` file)
167161
168-
If you are shure that you want to having the last version restarted,
169-
just delete the folder `~/production/myapp/var`. This folder contains
170-
the file `start_erl.data` that list the version number to start with.
171-
Deleting the `var` folder will automatically create it next time the app
172-
is started, with the last version number.
162+
Now you have an upgraded version running. But if you stop
163+
and restart it, the previous version will be launched instead
164+
of the most recent. This is useful because if your new version
165+
has some blocking bug, you can easily restart the service to the last
166+
working release.
167+
168+
If you are shure that you want to having the last version restarted,
169+
just delete the folder `~/production/myapp/var`. This folder contains
170+
the file `start_erl.data` that list the version number to start with.
171+
Deleting the `var` folder will automatically create it next time the app
172+
is started, with the last version number.
173173
174174
"""
175175
end

0 commit comments

Comments
 (0)