« back to all changes in this revision
Viewing changes to docs/process.rst
- browse files at revision 359
- compare with another revision
- download diff
- download tarball
- view history from revision 359
- Committer: Matthew Scott
- Date: 2013-02-01 18:49:00 UTC
- mfrom: (357.2.6 juju-gui)
- Revision ID: matthew.scott@canonical.com-20130201184900-0pq1u7lp1xxfkjbc
Merged with trunk; dragging no longer interrupted in multiple browser windows.
- files modified:
- CHANGES.yaml
added
removed
docs/process.rst
89
89
- Run ``python improv.py -f sample.json`` in the ``rapi-rollup`` Juju branch,
90
90
and run ``make server`` with the ``juju-ui`` branch.
91
91
92
* Do not forget to clear the browser cache: ``index.html`` may be sticking
92
- Do not forget to clear the browser cache: ``index.html`` may be sticking
93
93
around because of the cache.manifest.
94
* Verify that the browser reports no 404s and no Javascript errors in the
94
- Verify that the browser reports no 404s and no Javascript errors in the
95
95
console.
96
* QA the changes if possible, exploring different use cases (and edge cases).
97
* Spend between 60 and 120 seconds exploring the entire app. Do different
96
- QA the changes if possible, exploring different use cases (and edge cases).
97
- Spend between 60 and 120 seconds exploring the entire app. Do different
98
98
things every time. Try to break the app, generally.
99
99
100
100
- [Once we support multiple browsers, try them all, at least briefly.]
101
101
- Review the diff, including notes from the above as appropriate.
102
102
103
* Make sure that new code has tests.
104
* Make sure user-facing changes are described in ``CHANGES.yaml``.
105
* Make sure you can understand the new code. Ask for clarification if
103
- Make sure that new code has tests.
104
- Make sure user-facing changes are described in ``CHANGES.yaml``.
105
- Make sure you can understand the new code. Ask for clarification if
106
106
necessary.
107
* Consider the advice in this preferred `Software Architecture Cheat Sheet
107
- Consider the advice in this preferred `Software Architecture Cheat Sheet
108
108
<http://gorban.org/post/32873465932/software-architecture-cheat-sheet>`_
109
* Make sure changes to a file correspond to the naming conventions and other
109
- Make sure changes to a file correspond to the naming conventions and other
110
110
stylistic considerations local to that file, and within our project.
111
* Before you ask for a change, think and make sure you cannot compromise
111
- Before you ask for a change, think and make sure you cannot compromise
112
112
reasonably with the coder. If there is a low importance disagreement, in
113
113
general the coder's position should win.
114
* Only make a rework request if absolutely necessary. They are very
114
- Only make a rework request if absolutely necessary. They are very
115
115
expensive in time, money, and morale. One way to think about it is to
116
116
imagine filing a bug for the problem you see. Are you confident it is a
117
117
bug? If not, reconsider. If it would be a bug, how would you triage it?
143
143
<https://launchpad.net/juju-gui/stable>. If the most recent version string
144
144
is ``unreleased``, do the following.
145
145
146
* Decide what the next version number should be (see `Semantic Versioning
146
- Decide what the next version number should be (see `Semantic Versioning
147
147
<http://semver.org/>`_) and change ``unreleased`` to that value.
148
* Set a bzr tag for the release, e.g.: ``bzr tag 0.1.5``.
149
* Commit to the branch with this checkin message:
148
- Set a bzr tag for the release, e.g.: ``bzr tag 0.1.5``.
149
- Commit to the branch with this checkin message:
150
150
``bzr commit -m 'Set version for release.'``
151
* Push the branch directly to the parent (``bzr push :parent`` should work).
151
- Push the branch directly to the parent (``bzr push :parent`` should work).
152
152
153
153
- Run the tests and verify they pass: ``make test-prod`` and then
154
154
``make test-debug``.
155
155
- Create the tarball: ``FINAL=1 make distfile``. The process will end by
156
156
reporting the name of the tarball it made.
157
157
- In an empty temporary directory somewhere else on your system, expand the
158
tarball: ``tar xvzf PATH_TO_TARBALL``
159
- While still in the directory where you extracted the tar file, change to the
160
``build-prod`` directory and start a server: ``python -m SimpleHTTPServer
161
8888``.
158
tarball: ``tar xvzf PATH_TO_TARBALL``.
159
- Check that read and execute permissions for all are present on all files
160
and directories, especially in the ``node_modules/`` directory.
161
- Ensure that the ``build-prod/juju-ui/version.js`` file contains a version
162
string that combines the value in the branch's ``CHANGES.yaml`` with the
163
branch's revno.
164
- While still in the directory where you extracted the tar file, run the
165
command: ``NO_BZR=1 make prod``. Go to the URL shown in the terminal.
162
166
- In Chrome and Firefox, QA the application. At the very least, load the app,
163
167
open the charm panel, go to an inner page, and make sure there are no 404s
164
or Javascript errors in the console. We want a real QA script for the
165
future.
168
or Javascript errors in the console. Ensure that the ``/juju-ui/version.js``
169
URL shows the same version string as before. We want a real QA script for
170
the future.
171
- Also do the same checks after running the command ``NO_BZR=1 make debug``.
166
172
- For now, we will assume you would like to verify the release on the
167
173
Launchpad staging server. As we become more confident with this process,
168
174
this step may become unnecessary. In the branch, run ``FINAL=1 make
169
dist``. This will step you through signing the tarball, connecting
170
to Launchpad, and uploading the release.
175
dist``. This will step you through signing the tarball, connecting to
176
Launchpad, and uploading the release.
171
177
172
* Note that you may need to ask the webops to turn off the two-factor
173
authentication on your Launchpad staging account in order for this to
174
work. Go to the ``#launchpad-ops`` channel on the Canonical IRC server and
175
ask something like "webops, could you disable 2FA on my staging account?"
176
* When Launchpad asks you what level of permissions to grant, assuming you
178
- If you have two-factor authentication enabled on Launchpad, the staging
179
server will ask for a one-time password: be sure to have your device
180
available. (If you are a Canonical collaborator, you may try and ask the
181
webops to turn off the two-factor authentication on your Launchpad staging
182
account, but it may not be possible anyway. Go to the ``#u1-as`` channel
183
on the Canonical IRC server and ask something like "webops, could you
184
disable 2FA on my staging account?")
185
- When Launchpad asks you what level of permissions to grant, assuming you
177
186
are running on your own computer that you manage securely, the easiest
178
187
thing to do is hopefully also reasonably safe: accept that the computer
179
188
may perform all actions, indefinitely.
180
* Go to <https://staging.launchpad.net/juju-gui/stable> and verify that you
189
- Go to <https://staging.launchpad.net/juju-gui/stable> and verify that you
181
190
see a new release and a new download file.
182
* Download the file, expand it in a temporary directory, run ``python -m
183
SimpleHTTPServer 8888``, and do a quick double-check in the browser that
184
it is what you expect. Looking at ``juju-ui/version.js`` should also show
185
you the version you expect.
186
* This is a final release. Consider asking others to verify the package on
187
staging.
191
- Download the file and compare it to the original tarball in the
192
``release/`` directory, verifying that they are identical (hint: use the
193
``cmp`` command).
194
- This is a final release. Consider asking others to verify the package on
195
staging. If there are problems, you will have to delete the release from
196
staging, fix the problems and restart the process. However, *do not*
197
reuse the version number that you deleted. A deleted release is dead,
198
not invisible, and the next, fixed release should increase the revision
199
number.
188
200
189
201
- Now it is time for the actual, real release. Head back to your branch and
190
202
run ``FINAL=1 PROD=1 make dist``. The computer will again walk you
191
through the process.
203
through the process and upload the release, this time to production.
192
204
193
* Note that, one time per computer, you will again have to accept the
205
- Note that, one time per computer, you will again have to accept the
194
206
Launchpadlib security token: In Launchpad, the staging site and the
195
207
production have fully separate databases, including authentication. What
196
208
is done in production will in many cases eventually be copied over to
198
210
199
211
- Go to <https://launchpad.net/juju-gui/stable> and verify that you see
200
212
a new release and a new download file.
201
202
213
- Set the version back to ``unreleased`` by doing the following.
203
214
204
* Restore ``- unreleased:`` as most recent version string in
215
- Restore ``- unreleased:`` as most recent version string in
205
216
``CHANGES.yaml``.
206
* Commit to the branch with this checkin message:
217
- Commit to the branch with this checkin message:
207
218
``bzr commit -m 'Set version back to unreleased.'``
208
* Push the branch directly to the parent (``bzr push :parent`` should work).
219
- Push the branch directly to the parent (``bzr push :parent`` should work).
209
220
210
221
You are done!
211
222
220
231
found on `Launchpad <https://launchpad.net/juju-gui/trunk>`_.
221
232
- Run the tests and verify they pass: ``make test-prod`` and then
222
233
``make test-debug``.
223
- Create the tarball: ``make distfile``. It will end by reporting the name of
224
the tarball it made.
234
- Create the tarball: ``make distfile``. The process will end by reporting
235
the name of the tarball it made.
225
236
- In an empty temporary directory somewhere else on your system, expand the
226
237
tarball: ``tar xvzf PATH_TO_TARBALL``.
227
- Looking at ``build-prod/juju-ui/version.js`` should show you a version string
228
that combines the value in the branch's ``CHANGES.yaml`` with the branch's
229
revno.
230
- While still in the directory where you extracted the tar file, change to the
231
``build-prod`` directory and start a server: ``python -m SimpleHTTPServer
232
8888``.
238
- Check that read and execute permissions for all are present on all files
239
and directories, especially in the ``node_modules/`` directory.
240
- Ensure that the ``build-prod/juju-ui/version.js`` file contains a version
241
string that combines the value in the branch's ``CHANGES.yaml`` with the
242
branch's revno.
243
- While still in the directory where you extracted the tar file, run the
244
command: ``NO_BZR=1 make prod``. Go to the URL shown in the terminal.
233
245
- In Chrome and Firefox, QA the application. At the very least, load the app,
234
246
open the charm panel, go to an inner page, and make sure there are no 404s
235
or Javascript errors in the console. We want a real QA script for the
236
future.
247
or Javascript errors in the console. Ensure that the ``/juju-ui/version.js``
248
URL shows the same version string as before. We want a real QA script for
249
the future.
250
- Also do the same checks after running the command ``NO_BZR=1 make debug``.
237
251
- For now, we will assume you would like to verify the release on the
238
252
Launchpad staging server. As we become more confident with this process,
239
253
this step may become unnecessary. In the branch, run ``make dist``.
240
254
This will step you through signing the tarball, connecting to
241
255
Launchpad, and uploading the release.
242
256
243
* Note that you may need to ask the webops to turn off the two-factor
244
authentication on your Launchpad staging account in order for this to
245
work. Go to the ``#launchpad-ops`` channel on the Canonical IRC server and
246
ask something like "webops, could you disable 2FA on my staging account?"
247
* When Launchpad asks you what level of permissions to grant, assuming you
257
- If you have two-factor authentication enabled on Launchpad, the staging
258
server will ask for a one-time password: be sure to have your device
259
available. (If you are a Canonical collaborator, you may try and ask the
260
webops to turn off the two-factor authentication on your Launchpad staging
261
account, but it may not be possible anyway. Go to the ``#u1-as`` channel
262
on the Canonical IRC server and ask something like "webops, could you
263
disable 2FA on my staging account?")
264
- When Launchpad asks you what level of permissions to grant, assuming you
248
265
are running on your own computer that you manage securely, the easiest
249
266
thing to do is hopefully also reasonably safe: accept that the computer
250
267
may perform all actions, indefinitely.
251
* Go to <https://staging.launchpad.net/juju-gui/trunk> and verify that you
268
- Go to <https://staging.launchpad.net/juju-gui/trunk> and verify that you
252
269
see a new release and a new download file.
253
* Download the file, expand it in a temporary directory, run ``python -m
254
SimpleHTTPServer 8888``, and do a quick double-check in the browser that
255
it is what you expect. Looking at ``juju-ui/version.js`` should also show
256
you the version you expect, as seen in the similar earlier step above.
270
- Download the file and compare it to the original tarball in the
271
``release/`` directory, verifying that they are identical (hint: use the
272
``cmp`` command).
257
273
258
274
- Now it is time for the actual, real release. Head back to your branch and
259
275
run ``PROD=1 make dist``. The computer will again walk you through the
260
process.
276
process and upload the release.
261
277
262
* Note that, one time per computer, you will again have to accept the
278
- Note that, one time per computer, you will again have to accept the
263
279
Launchpadlib security token: In Launchpad, the staging site and the
264
280
production have fully separate databases, including authentication. What
265
281
is done in production will in many cases eventually be copied over to
Loggerhead is a web-based interface for Breezy
Version: 2.0.1