¿Existen alternativas de código abierto para Bitbucket, Github, Kiln y herramientas similares de navegación y administración de DVCS? [cerrado]

Conozco varias herramientas / servicios que proporcionan navegación y administración de DVCS, como Bitbucket , Github , Kiln , SCM-Manager y Rhodecode .

Sin embargo, el caso de uso que estoy considerando es tal que:

1. Cualquier código fuente debe residir en los servidores internos de un empleador.
2. La solución debe ser de código abierto.
3. Debería proporcionar una experiencia similar a Bitbucket o Github, incluyendo un wiki de proyecto, navegación y gestión de repositorios, y aspectos de codificación social como la revisión de código.
4. La solución debe tener soporte mercurial (si no soporte para otros DVCS).

De estos, solo SCM-Manager y RhodeCode se acercan, ya que se pueden instalar en sus propios servidores y son de código abierto. Sin embargo, no tienen la experiencia Bitbucket o Github. No hay un rastreador de problemas o wiki y la interfaz de usuario, aunque funcional, no está a la altura de Github o Bitbucket.

Puedo acercarme a Trac o Redmine con sus navegadores de repositorio, pero desafortunadamente no tienen ninguna capacidad de gestión de repositorio.

¿Existen otras herramientas de código abierto que brinden una experiencia similar a Bitbucket, Github o Kiln?

Me gustaría echar un vistazo a fósiles. Es el sistema que los desarrolladores de sqlite usan, internamente, aparentemente. También usa sqlite, que es una buena tecnología sólida ... que es agradable y portátil, además de simple y confiable.

Tiene una buena, aunque austera , interfaz de usuario (que creo que corresponde a la naturaleza de un objetivo orientado a la productividad como el que usted describe). ((Asegúrese de revisar el tema "gris". Es mucho menos "router-admin" que el "tema" predeterminado, si pudiera llamarlo así).) Me atrajo por sus raíces como CGI sistema basado, porque soy un tonto para CGI. Los resultados de esa herencia son realmente muy interesantes, ya que este sistema tiene un modo único, SOLO JSON, que tiene todo tipo de posibilidades de implementación interesantes.

Lo mencionan, pero vale la pena repetir que tiene 0 dependencias. Sin php, sin mySQL, sin python. Nada Es su propio ejecutable binario, y funciona en muchas plataformas. Deseo que más proyectos "piensen" de la misma manera.

No estoy afiliado a ellos, así que simplemente citaré las extolaciones de su página de inicio , que generalmente estoy de acuerdo con ... también eche un vistazo a las preguntas y críticas ...

Seguimiento de errores y wiki: además de hacer un control de versiones distribuido como Git y Mercurial, Fossil también admite el seguimiento distribuido de errores, wiki distribuido y un mecanismo de blog distribuido, todo en un solo paquete integrado.

Interfaz web: Fossil tiene una interfaz web integrada y fácil de usar que simplifica el seguimiento de proyectos y promueve la conciencia situacional. Simplemente escriba "fossil ui" dentro de cualquier proceso de pago y Fossil abre automáticamente su navegador web en una página que proporciona un historial gráfico detallado e información de estado de ese proyecto.

Sincronización automática: Fossil admite el modo "sincronización automática" que ayuda a mantener los proyectos en marcha al reducir la cantidad de bifurcación innecesaria y la fusión a menudo asociada con proyectos distribuidos.

Autónomo: Fossil es un ejecutable independiente que contiene todo lo necesario para administrar la configuración. La instalación es trivial: simplemente descargue un binario precompilado para Linux, Mac o Windows y póngalo en su $ PATH. El código fuente fácil de compilar está disponible para usuarios en otras plataformas. Las fuentes fósiles también son en su mayoría autónomas, y solo requieren la biblioteca "zlib" y la biblioteca C estándar para construir.

Redes simples: Fossil utiliza HTTP antiguo simple (con soporte de proxy) para todas las comunicaciones de red, lo que significa que funciona bien desde detrás de firewalls restrictivos. El protocolo es eficiente en ancho de banda hasta el punto de que Fossil se puede utilizar cómodamente a través de una conexión de acceso telefónico a Internet.

CGI habilitado: no se requiere ningún servidor para usar fósiles. Pero un servidor facilita la colaboración. Fossil admite tres configuraciones de servidor diferentes pero simples. El más popular es un script CGI de 2 líneas. Este es el enfoque utilizado por los repositorios fósiles de alojamiento propio.

Robusto y confiable: Fossil almacena contenido utilizando un formato de archivo duradero en una base de datos SQLite para que las transacciones sean atómicas incluso si se ven interrumpidas por una pérdida de energía o un bloqueo del sistema. Además, las autoverificaciones automáticas verifican que todos los aspectos del repositorio sean consistentes antes de cada confirmación. En más de tres años de operación, ningún trabajo se ha perdido después de haber sido comprometido con un repositorio de Fossil.

Actualización: en lugar de aludir a la interfaz, aquí hay un vistazo rápido ... Como puede ver, definitivamente es simple ... Pero eso también significa una pizarra limpia para la personalización ... Solo una hoja de estilo y un encabezado / pie de página / tipo de cuerpo sistema de plantillas. Es mejor escribir una historia corta que reescribir el libro de otra persona, IMO.

Gitorious es de código abierto y puede instalarlo en su propio servidor utilizando los scripts proporcionados por la edición comunitaria de Gitorious (consulte http://www.getgitorious.com/installer ). Gitorious ahora tiene soporte para wikis y seguimiento de problemas. También hay una imagen de Docker disponible para que se ejecute rápidamente.

Otra opción sería Gitlab, que es básicamente un clon de GitHub, no tan maduro como deslumbrante pero está en desarrollo con lanzamientos mensuales.

También puede consultar más opciones aquí.

Sus restricciones son bastante específicas, pero creo que puede obtener los resultados que busca con los complementos de ChiliProject +.

ChiliProject es una bifurcación de Redmine que utiliza versiones actualizadas de Ruby / Rails. Admite muy bien git y mercurial, y replica la funcionalidad de problemas de Github que parece que está buscando al analizar mensajes de confirmación (es decir, refs 291en una confirmación se vincularía una confirmación con el problema # 291).

También hay complementos de Redmine / ChiliProject que brindan servicios como revisión de código, resaltado de sintaxis y otras sutilezas que ofrece Github, etc.

Hay otras opciones, JIRA, etc., pero (en mi humilde opinión) no proporcionan la flexibilidad o la riqueza de la funcionalidad que proporciona la bifurcación ChiliProject de Redmine + la multitud de complementos disponibles. No hay mucho que Github y / o BitBucket hagan por usted que ChiliProject (posiblemente con complementos disponibles gratuitamente) no pueda hacer; y la belleza es que, si aún no existe, generalmente es bastante trivial implementarlo usted mismo.

Si esto suena más de lo que necesita ... No lo he probado todavía, pero GitLab también parece interesante ... no parece tener la arquitectura de extensión o plugin de Redmine / Chili, pero si está buscando para un clon de código abierto de Github con la mayoría del conjunto de características principales (y no es necesario que admita múltiples DVCS), se ve bastante bien.

Allura http://sf.net/p/allura debería cumplir con los requisitos. Es la plataforma para todos los proyectos nuevos (o actualizados) en SourceForge y es de código abierto. Es compatible con Mercurial y wikis, además de muchas más herramientas (Git, SVN, rastreador de tickets, foros, etc.). No tiene "revisión de código" pero admite solicitudes de bifurcación y fusión para repositorios Mercurial y Git.

Está escrito en Python y usa MongoDB y Solr para el almacenamiento de datos.

Allura también se encuentra actualmente en la incubadora de Apache: http://incubator.apache.org/projects/allura.html

Trabajo para SourceForge y ayudo a desarrollar Allura.

Para exactamente el mismo problema en el trabajo, utilizamos un ecosistema compuesto por:

• Redmine para el seguimiento de problemas
• RhodeCode para la gestión de repositorios
• Jenkins para la integración y la implementación continuas (tenemos trabajos para tareas de implementación y actualización a las que se les pueden asignar permisos de forma granular, y usted obtiene la pista de auditoría de forma gratuita)
• Active Directory para la autenticación (todo lo anterior puede integrarse sin problemas)

La integración de DVCS en Redmine ha mejorado a pasos agigantados en las versiones posteriores, actualicé hace unas semanas y estoy extremadamente satisfecho de que la mayoría de las "trampas" hayan desaparecido.

Ejecuto los servidores Redmine y RhodeCode en el mismo host porque Redmine aún no admite repositorios remotos de HG. Jenkins se ejecuta en varios otros hosts.

Utilizo un gancho RhodeCode para desencadenar tirones mercuriales en Redmine. No puedo usar un gancho para los tirones de Jenkins debido a JENKINS-13717 , pero ya envié un parche para esto y supongo que será aceptado bastante rápido. Mientras tanto, solo sondeo los repositorios de HG cada pocos minutos.

Todo se ejecuta en Debian 6.0 sobre Nginx proxy inverso para obtener la terminación SSL (todo esto solo se usa a través de SSL). Recientemente, todo el paquete se movió a un clúster ProxMox para virtualizarlo todo con excelentes resultados hasta ahora. En caso de que no conozca el producto, debe echarle un vistazo. Es uno de esos productos tipo "¡ No puedo creer que esto exista y no lo sabía y OMG también es de código abierto! ". Ejecutamos estos servicios en contenedores OpenVZ que se migran fácilmente de un host a otro para reparaciones / actualizaciones de hardware. En el mismo clúster también ejecutamos un montón de máquinas virtuales KVM para pruebas automatizadas en plataformas Windows.

Estoy extremadamente feliz con este ecosistema. Ha mejorado la capacidad de nuestro equipo de desarrollo / control de calidad para reproducir problemas y realizar un seguimiento de los cambios por un amplio margen. Solo algunas advertencias:

• Si utiliza Rhodecode, no lo configure en SQLite. Use MySQL u otro DBMS real. No es realmente migrable después del hecho, y SQLite solo toma 1 conexión a la vez, lo que resulta en bloqueos y tiempos de espera divertidos (vea RhodeCode # 439 ). Esto se vuelve doloroso si Jenkins está sondeando el repositorio continuamente a medida que recibe mensajes de error de vez en cuando (vea el comentario anterior sobre el problema de Jenkins).
• Realmente no puede enfatizar lo suficiente a sus desarrolladores que en Mercurial, el número de confirmación "132" no significa nada para todos los demás en la red, ya que esos números son solo locales . Al hablar sobre los conjuntos de cambios dentro de los tickets de Redmine, use el número de revisión local que puede obtener del navegador de repositorios (que es el mismo en RhodeCode y Redmine, ya que se ejecutan en la misma máquina) o úselo commit:abcd1234.

No dudo en recomendar esta configuración, ya que estoy muy contento con ella. Si necesita ayuda para configurar un servicio específico o desea ver mis archivos de configuración, no dude en preguntar.

Eche un vistazo a cydra: https://github.com/mensi/cydra tiene soporte para

• Subversion (HTTP)
• Git (HTTP y SSH en puerto separado)
• Mercurial (HTTP)
• Trac

Funciona en un enfoque basado en proyectos que le permite crear un proyecto y asignarle múltiples repositorios (como máximo un repositorio SVN). La autenticación se basa en complementos individuales (lo integramos en nuestro ldap).

Lo usamos para nuestra plataforma de codificación https://code.vis.ethz.ch . Por el momento no hay ningún soporte para la revisión de código, pero podría agregarse fácilmente como un complemento.

No puedo publicar capturas de pantalla porque no tengo suficiente reputación.

Considere usar GitLab https://about.gitlab.com/ ya que cumple con la mayoría de sus requisitos:

1. Puedes instalarlo localmente
2. Tiene licencia de expatriado del MIT
3. Tiene un wiki (respaldado por git), navegación de repositorio, administración de acceso detallada (niveles de acceso múltiples, ramas protegidas, integración ldap, etc.) y tiene solicitudes de fusión para la revisión y discusión del código (incluidos los comentarios de línea)
4. No admite mercurial sino solo git

También tiene un buen rastreador de problemas o puede vincularlo a un rastreador de problemas externo. Puede probar sus solicitudes de fusión con GitLab CI si lo desea. GitLab ha estado creciendo rápidamente y está en uso por más de 25,000 organizaciones.

Divulgación: soy el CEO y cofundador de GitLab BV