Voy a responder por un proyecto de tamaño mediano en las condiciones con las que estoy familiarizado, es decir, entre 100K y 1M de líneas de código fuente y hasta 10 desarrolladores. Esto es lo que estamos usando ahora, para un proyecto que comenzó hace dos meses en agosto de 2013.

Sistema de compilación y organización del código:

• un script de shell compatible con el código fuente define la ruta y otras variables para nuestro proyecto
• uno .el archivo ocamlinit en la raíz de nuestro proyecto carga un montón de bibliotecas al iniciar un sesión de nivel superior
• omake, que es rápido (con la opción-j para compilaciones paralelas); pero evitamos hacer complementos omake personalizados locos
• un Makefile raíz contiene todos los destinos esenciales (setup, build, test, clean y más)
• un nivel de subdirectorios, no dos
• la mayoría de los subdirectorios se construyen en una biblioteca OCaml
• algunos subdirectorios contienen otras cosas (setup, scripts, etc.)
• OCAMLPATH contiene la raíz del proyecto; cada subdirectorio de biblioteca produce un archivo META, haciendo que todas las partes OCaml de los proyectos sean accesibles desde el nivel superior usando # require.
• solo se construye un ejecutable OCaml para todo el proyecto (ahorra mucho tiempo de enlace; todavía no se sabe por qué)
• las bibliotecas se instalan a través de un script de instalación utilizando opam
• los paquetes opam locales están hechos para software que no está en el repositorio opam oficial
• utilizamos un conmutador opam que es un alias que lleva el nombre de nuestro proyecto, evitando conflictos con otros proyectos en la misma máquina

Edición del código fuente:

• emacs con paquetes opam ocp-indent y ocp-index

Control y gestión de fuentes:

• usamos git y github
• todo el código nuevo es revisado por pares a través de solicitudes de extracción de github
• los tarballs para bibliotecas que no son opam y que no son github se almacenan en un repositorio git separado (que puede desaparecer si el historial se vuelve demasiado grande)
• las bibliotecas de vanguardia existentes en github se bifurcan en nuestro github cuenta e instalado a través de nuestro propio paquete local de opam

Uso de OCaml:

• OCaml no compensará las malas prácticas de programación; enseñar el buen gusto está más allá del alcance de esta respuesta. http://ocaml.org/learn/tutorials/guidelines.html es un buen punto de partida.
• OCaml 4.01.0 hace que sea mucho más fácil que antes reutilizar etiquetas de campos de registro y constructores de variantes (es decir, type t1 = {x:int} type t2 = {x:int;y:int} let t1_of_t2 ({x}:t2) : t1 = {x} ahora funciona)
• tratamos de no usar extensiones de sintaxis camlp4 en nuestro propio código
• no usamos clases y objetos a menos que sea requerido por alguna biblioteca externa
• en teoría desde OCaml 4.01.0 deberíamos preferir variantes clásicas sobre variantes polimórficas
• usamos excepciones para indicar errores y los dejamos pasar felizmente hasta que nuestro bucle del servidor principal los atrapa y los interpreta como "error interno" (predeterminado), "solicitud incorrecta" o algo más
• las excepciones como Exit o Not_found se pueden usar localmente cuando tiene sentido, pero en el módulo interfaces preferimos usar opciones.

Bibliotecas, protocolos, frameworks:

• usamos baterías para todas las funciones de commodity que faltan en la biblioteca estándar de OCaml; para el resto tenemos una biblioteca "util"
• usamos Lwt para la programación asíncrona, sin las extensiones de sintaxis, y el operador bind (>>=) es el único operador que usamos (si tiene que saberlo, usamos a regañadientes el preprocesamiento camlp4 para un mejor seguimiento de excepciones en bind punto).
• utilizamos HTTP y JSON para comunicarnos con software de terceros y esperamos que todos los servicios modernos proporcionen dichas API
• para servir HTTP, ejecutamos nuestro propio servidor SCGI (ocaml-scgi) detrás de nginx
• como cliente HTTP utilizamos Cohttp
• para la serialización JSON usamos atdgen

Servicios"en la nube":

• usamos muchos de ellos, ya que generalmente son baratos, fáciles de interactuar y resuelven problemas de escalabilidad y mantenimiento para nos.

Pruebas:

• tenemos un objetivo make / omake para pruebas rápidas y otro para pruebas lentas
• las pruebas rápidas son pruebas unitarias; cada módulo puede proporcionar una función de "prueba"; a test.ml el archivo ejecuta la lista de pruebas
• las pruebas lentas son aquellas que implican ejecutar múltiples servicios; estos están diseñados específicamente para nuestro proyecto, pero cubren tanto como sea posible como un servicio de producción. Todo se ejecuta localmente en Linux o macOS, excepto para los servicios en la nube para los que encontramos maneras de no interferir con la producción.

Configurar todo esto es bastante trabajo, especialmente para alguien que no está familiarizado con OCaml. Todavía no hay un framework que se ocupe de todo eso, pero al menos tienes la opción de las herramientas.