Release Process

The federated wiki code is spread over several repos and is published as several npm modules. We're thinking this is a big improvement. But one really has to think to deploy revisions.

See Hacking Wiki's Methods for specific example.

html

I develop with local copies of everything on a laptop. I debug first in the node version then check that ruby is ok with changes.

npm link wiki-client (for each server)

grunt watch (in wiki-client)

grunt build && npm start (with each change)

grunt build && bundle exec rackup -s webrick -p 1111

html

html

html

The client javascript should be coded to work with many versions of the browser. Updates start with the client.

git clone (or checkout master)

npm install

grunt build

npm version patch

git push --tags

npm publish

html

We rev the node server when wiki-client changes. This may involve revising version numbers on the dependencies if there are coordinated changes.

cd wiki-node

npm version patch

rm -r node_modules

npm install

run tests

git push

npm publish

html

The ruby version includes building the client code from node package source. Like node, this may involve revisions to version dependencies.

git pull

edit dependency in package.json

commit as "update to wiki-client version 0.0.m"

rm -r node_modules

npm install

grunt build

run tests

git push

html

For now we are still serving fed.wiki.org with the ruby version. It isn't so important that deploys here track code development closely.

ssh fed.wiki.org

screen -r farm

git pull

bundle exec rackup -s webrick -p 8080

html

We sometimes build on one machine and copy files to another. This saves keeping the build environment working which is surprisingly hard. It also means that updates don't interrupt logged in users.

Client-side files can update without a restart.

code

Some server-side files can hot-update too.

code

Update Track Updates for those who care.