[ocaml-infra] Staging Build and Deployment of ocaml.org

[David Sheets]

On Mon, Mar 17, 2014 at 2:19 PM, Ashish Agarwal <agarwal1975 at gmail.com> wrote:
> On Mon, Mar 17, 2014 at 7:49 AM, David Sheets <sheets at alum.mit.edu> wrote:
>
>> 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
>
>
> All of these could be obtained with a single server. Can you explain the
> benefits of splitting into a build server and static server. I'm just
> wondering why the extra work would be worth it.

They could be. By splitting the build and serve functions we get:

1. Extremely simple, hard-to-break serving functionality potentially specialized
2. Build environment specification and web server irrelevance

That is, it is nice not having to worry about service interruptions
due to build software updates or misbehaving builds.

We could certainly go down the combined build/server image route but
this seems heavier weight than a stupid simple server which responds
with pre-built files from free, on-demand instances.

With a combined solution, I now need to worry about
downloading/uploading the current server's machine image and running
it manually to test. With a solution that uses on-demand instances, I
only need to request a build of my repository to test.

Of course, both models are possible under a combined model but the
combined image would get even more complicated with the machinery to
monitor repositories, initiate builds, and serve logs and development
sites. There is a fixed amount of complexity in these requirements, I
believe. The question is: where do we push this complexity and whose
problem is it?

David