Currently, building and deploying the [marketing site](https://about.gitlab.com/) takes a very long time—nearly a half hour for the longest of several jobs in the process and around an hour for the whole process with even the smallest of changes. Let's consider and discuss options to speed things up. These options may include: * **DRYing Things Up:**\* We could optimize several jobs that currently rebuild, retest, and redeploy unchanged content. This could involve Middleman caching, new features of Middleman 4 and/or 5, and/or features of a different system. * **Dividing the Workload:** We could separate the Handbook and/or the Blog from the marketing site. * **Your Other Awesome Idea:** Tell us about it! \* *DRY: Don't Repeat Yourself* **From [a recent discussion via Slack](https://gitlab.slack.com/archives/C81PT2ALD/p1568159162046500?thread_ts=1568058470.040800&cid=C81PT2ALD) (internal):** > Our longest-running task seems to be `build_branch`, which takes several times as long on GitLab as a local `bundle exec middleman`, suggesting that there is more to the slowness than Middleman inefficiencies. That said, both do seem to be slowed by the same thing, at least in general: they seem to be repeating things that have already been done. Both rebuild things that haven’t changed, but `build_branch` says it uploads almost 15,000 files, including over a thousand images, even when no images have changed. I don’t see timestamps for that part of the task and I don’t yet know the details of how the uploads are performed, but I suspect that’s rather a large bottleneck. > > In addition to that task, at least a few other tasks could be skipped or streamlined so they’re not repeating already-completed tasks such as re-processing pictures when pictures haven’t changed or checking code quality for code that hasn’t changed. cc @sytses @bmarnane @laurenbarker