[ocaml-infra] Staging Build and Deployment of ocaml.org
Philippe Wang
philippe.wang at gmail.com
Fri Mar 21 04:16:02 GMT 2014
On 17 Mar 2014, at 11:49 am, David Sheets <sheets at alum.mit.edu> wrote:
> Our present deployment workflow unnecessarily relies on a single build
> environment running on the same (?) machine as the serving system.
>
> ocaml.org is entirely static with a refresh on the order of minutes. I
> propose we take advantage of this feature to move to a fully staged
> build and deployment solution.
>
> Specifically, I'd like to see:
>
> 1. Generated assets and build logs publicly accessible
> 2. Build environment specification (e.g. "this stock Ubuntu image").
> 3. History
>
> I'd like to suggest the following design from back-to-front:
>
> 1. Travis CI builds ocaml.org on commit hook to source repository
> 2. Travis CI pushes successful builds to static asset repository
> 3. Server checks out static asset repository on commit hook
>
> If we would like to stage development and production, the following may satisfy:
>
> 1. Travis CI builds ocaml.org on commit hook to source repository
> 2. Travis CI pushes successful builds to static assets
> 3. beta.ocaml.org checks out static asset repository on commit hook to
> static assets
> 4. ocaml.org checks out static asset repository on special commit hook
> to static assets
>
> Where "special commit hook" is a commit by a non-Travis user which
> contains as its commit message a human/machine-readable description of
> the deployment. These commits can themselves be consumed to generate a
> site change log which is exposed on the site.
>
> This approach should help us achieve faster iteration on the
> mechanical components of the site, ease build debugging, ease build
> reproduction, and offer a pre-built image of the site's assets.
>
> What do you think?
>
> David
Basically I agree with all this. :-)
If we don’t want the builds to take “forever”, we need to think of caching the .opam folder (because the packages take quite some time to build, especially since we use opam2web which brings a lot of dependencies) and the built version of ocaml.org (it’s sort of mandatory to cache some data anyway, e.g., RSS feeds in case the remote server’s unavailable).
Philippe
P.S.
> $ opam install opam2web
> The following actions will be performed:
> - install ocamlfind.1.4.0 [required by opam2web]
> - install cmdliner.0.9.4 [required by opam2web]
> - install extlib-compat.1.6.1 [required by opam2web]
> - install lwt.2.4.4 [required by opam2web]
> - install menhir.20130912 [required by opam2web]
> - install ocamlgraph.1.8.3 [required by opam2web]
> - install omd.0.9.7 [required by opam2web]
> - install ounit.2.0.0 [required by opam2web]
> - install re.1.2.1 [required by opam2web]
> - install type_conv.109.60.01 [required by opam2web]
> - install typerex.1.99.6-beta [required by opam2web]
> - install ulex.1.1 [required by opam2web]
> - install xmlm.1.2.0 [required by opam2web]
> - install js_of_ocaml.1.4.0 [required by opam2web]
> - install dyntype.0.9.0 [required by opam2web]
> - install sexplib.111.03.00 [required by opam2web]
> - install ocp-build.1.99.6-beta [required by opam2web]
> - install uri.1.4.0 [required by opam2web]
> - install cudf.0.6.3 [required by opam2web]
> - install cow.0.8.1 [required by opam2web]
> - install dose.3.1.2 [required by opam2web]
> - install opam-lib.1.1.1 [required by opam2web]
> - install opamfu.0.1.1 [required by opam2web]
> - install opam2web.1.3.1
> 24 to install | 0 to reinstall | 0 to upgrade | 0 to downgrade | 0 to remove
> Do you want to continue ? [Y/n]
More information about the Infrastructure
mailing list