travis-ci/travis-core — pull request #138 by svenfuchs (2012-11-18 15:26:29+00:00)
Title: Sf register services

On the quest of eventually splitting up travis-core.

This currently includes:

* abstracting the services api further by registering service classes
explicitly so that clients do not have to depend on the service class
hierarchie

* flattening the namespaces for service classes so they (mostly) still map
to the names they're registered with (e.g. `:find_builds` maps to
`Services::FindBuilds` instead of `Services::Builds::FindAll`)

* moving services that are related to aspects other than core domain models
(such as github) or aspects that are run by small apps (such as enqueue,
logs) into separate directories so that they can be moved over soon

* adding additional service classes for where travis-hub and travis-logs
amqp handlers were still accessing models directly (e.g. worker status
updates, log updates)

After doing this work I believe that I have a pretty clear picture of how
the eventual architecture can look like in terms of splitting travis-core
up into smaller repos.

Here's what I imagine:

* All logic relevant to a given request incoming from the api, amqp or
sidekiq should be in service classes so that they can be easily plugged
into a different receiver.

* "Handlers" for amqp, sidekiq and whatever other messaging/queueing tech
we might choose in future should contain nothing else but logic that
is required to turn the incoming message into whatever the service
class expects.

* Services that now sit in travis-core but are relevant to a certain
deployable app (travis-enqueue, travis-logs, travis-gatekeeper etc)
should be moved to these apps/repos but kept in a way so they are also
loadable from other apps (e.g. travis-hub)

This will give us:

* The ability to still move responsibility for running certain aspects
around (e.g. handling logs in travis-hub vs travis-logs) by switching a
feature flip with minimal extra code/bugs/complexity.

* A much leaner travis-core repository that can be stripped down to mostly
just core model classes (which in future should also be slimmed down further)

* Much faster development cycles because we don't have to deploy up to 10 apps
for testing a few changes in travis-core any more (since that has been broken
up)

Examples:

Stuff from travis-core/lib/travis/enqueue can go to the travis-enqueue repo,
stuff from travis/logs to travis-logs, travis/requests to travis-gatekeeper,
travis/github to a new repo travis-github.

More future refactorings that I plan to do:

* Move travis/addons and travis/mailer to travis-tasks

* Turn travis/api into travis/serializers, make it pluggable just like
addons and services, then split it up and move serializers to their
respective client libs. E.g. http api serializers can go to the travis-api
repo, task/addon serializers to travis-tasks etc.

* Possibly move travis/notifications and travis/features to travis-support