Existem alternativas de código aberto para Bitbucket, Github, Kiln e ferramentas semelhantes de navegação e gerenciamento DVCS? [fechadas]


68

Estou ciente de várias ferramentas / serviços que fornecem navegação e gerenciamento DVCS, como Bitbucket , Github , Kiln , SCM-Manager e Rhodecode .

No entanto, o caso de uso que estou considerando é um dos seguintes:

  1. Qualquer código-fonte deve residir nos servidores internos do empregador.
  2. A solução deve ser de código aberto.
  3. Ele deve fornecer uma experiência semelhante ao Bitbucket ou Github, incluindo um wiki do projeto, navegação e gerenciamento de repositório e aspectos de codificação social, como revisão de código.
  4. A solução deve ter suporte mercurial (se não houver suporte para outros DVCSs).

Destes, apenas o SCM-Manager e o RhodeCode se aproximam, pois podem ser instalados em seus próprios servidores e são de código aberto. No entanto, eles não têm a experiência Bitbucket ou Github. Não há rastreador de problemas ou wiki e a interface do usuário, embora funcional, não é compatível com o Github ou o Bitbucket.

Posso me aproximar do Trac ou Redmine com seus navegadores de repositório, mas infelizmente eles não têm nenhum recurso de gerenciamento de repositório.

Existem outras ferramentas de código aberto por aí que proporcionariam uma experiência semelhante ao Bitbucket, Github ou Kiln?


4
O GitHub Enterprise é executado na rede interna. enterprise.github.com


4
@sylvanaar Para meu conhecimento, o redmine não fornece recursos de gerenciamento de repositório, apenas navegação no repositório.
Ryan Taylor

3
gitlabhq.com é o mais próximo que eu vi para GitHub
Andrew T Finnell

8
Eu voto para reabrir. Esta é uma pergunta extremamente popular. Por que fechá-lo? Podemos pelo menos migrá-lo para outro lugar?
William Leara

Respostas:


31

Eu daria uma olhada no Fossil. É o sistema que os desenvolvedores do sqlite usam, internamente, aparentemente. Ele também usa o sqlite, que é uma boa tecnologia sólida ... agradável e portátil - além de simples e confiável.

Ele tem uma interface de usuário boa e austera (que eu acho que comporta a natureza de um objetivo orientado à produtividade, como você descreve). ((Não deixe de conferir o tema "cinza". É muito menos "roteador-administrador" do que o "tema" padrão, se é que você pode chamar assim).)) Fui atraído por isso por causa de suas raízes como CGI sistema baseado, porque eu sou um otário para CGI. Os resultados dessa herança são realmente muito interessantes, pois esse sistema possui um modo JSON-ONLY muito exclusivo, com todos os tipos de possibilidades de implementação interessantes.

Eles mencionam isso - mas vale a pena repetir que ele possui 0 dependências. Sem php, sem mySQL, sem python. Nada. É o seu próprio executável binário - e funciona em muitas plataformas. Desejo que mais projetos "pensem" da mesma maneira.

Eu não sou afiliado a eles, por isso, simplesmente citará as elogios de suas páginas de abertura , as quais geralmente concordo .. também dê uma olhada nas perguntas e críticas .

Rastreamento de bugs e wiki - Além de fazer o controle de versão distribuído como Git e Mercurial, o Fossil também suporta rastreamento de bugs distribuído, wiki distribuído e um mecanismo de blog distribuído, tudo em um único pacote integrado.

Interface da Web - A Fossil possui uma interface da Web integrada e fácil de usar que simplifica o rastreamento do projeto e promove a conscientização da situação. Basta digitar "interface do usuário fóssil" a partir de qualquer check-out e o Fossil abre automaticamente o seu navegador em uma página que fornece histórico gráfico detalhado e informações de status desse projeto.

Autosync - O Fossil suporta o modo "autosync", que ajuda a manter os projetos avançando, reduzindo a quantidade de bifurcações e combinações desnecessárias, muitas vezes associadas a projetos distribuídos.

Autônomo - O Fossil é um único executável independente que contém tudo o que é necessário para o gerenciamento de configurações. A instalação é trivial: basta baixar um binário pré-compilado para Linux, Mac ou Windows e colocá-lo no seu $ PATH. O código-fonte fácil de compilar está disponível para usuários em outras plataformas. As fontes fósseis também são praticamente independentes, exigindo apenas a construção da biblioteca "zlib" e da biblioteca C padrão.

Rede simples - o Fossil usa HTTP antigo simples (com suporte a proxy) para todas as comunicações da rede, o que significa que funciona bem por trás de firewalls restritivos. O protocolo é eficiente em termos de largura de banda, a ponto de o Fossil poder ser usado confortavelmente em uma conexão discada à Internet.

CGI ativado - nenhum servidor é necessário para usar fósseis. Mas um servidor facilita a colaboração. O Fossil suporta três configurações de servidor diferentes, porém simples. O mais popular é um script CGI de 2 linhas. Essa é a abordagem usada pelos repositórios fósseis auto-hospedados.

Robusto e confiável - o Fossil armazena conteúdo usando um formato de arquivo duradouro em um banco de dados SQLite, para que as transações sejam atômicas, mesmo se interrompidas por uma perda de energia ou falha no sistema. Além disso, as verificações automáticas verificam se todos os aspectos do repositório são consistentes antes de cada confirmação. Em mais de três anos de operação, nenhum trabalho foi perdido após ter sido comprometido com um repositório Fossil.

Atualização: em vez de fazer alusão à interface, aqui está uma rápida visão dela ... Como você pode ver, é definitivamente simples .. Mas isso também significa uma lista limpa para personalização .. Apenas uma única folha de estilo e um cabeçalho / rodapé / tipo de corpo sistema de modelos. Melhor escrever uma história curta do que reescrever o livro de outra pessoa, a IMO.

interface do usuário fóssil


3
+1 para fósseis. Eu o usei extensivamente aqui no trabalho, e a única "desvantagem" que eu vi é a zona na qual a tartaruga (git / hg / svn) se encaixa. No entanto, existe o projeto winfossil . Ele é hospedado em fóssil, se você quiser dar uma olhada na interface da web em um projeto além do próprio fóssil.
Spencer Rathbun

11
Fóssil é absolutamente incrível. Raramente é o que eu uso, mas é a verdade.
haylem

16

O Gitorious é de código aberto e você pode instalá-lo em seu próprio servidor usando scripts fornecidos pela edição da comunidade Gitorious (consulte http://www.getgitorious.com/installer ). Gitorious agora tem suporte para wikis e rastreamento de problemas. Há também uma imagem do Docker disponível para colocá-la em execução rapidamente.

Outra opção seria o Gitlab, que é basicamente um clone do GitHub, não tão maduro quanto vitorioso, mas está em desenvolvimento pesado com lançamentos mensais.

Você também pode conferir mais opções aqui


O processo de instalação do Gitorious foi simplificado. Você pode usar o script de instalação ( getgitorious.com/installer ) ou ir para o pronto para executar o VirtualBox imagem ( getgitorious.co/install-gitorious )
Peter Butkovic

O código é encontrado em gitorious.org/gitorious/mainline
The Demz

8

Suas restrições são bem específicas, mas acho que você pode obter os resultados que deseja com os plugins ChiliProject +.

O ChiliProject é um fork do Redmine que usa versões atualizadas do Ruby / Rails. Ele suporta git e mercurial muito bem, e replica a funcionalidade Github Issues que parece que você está procurando analisando mensagens de confirmação (ou seja, refs 291em uma confirmação vincularia uma confirmação à edição # 291).

Também existem plugins Redmine / ChiliProject que fornecem recursos como revisão de código, destaque de sintaxe e outras sutilezas fornecidas pelo Github, etc. que podem não estar óbvia ou prontamente disponíveis nos concorrentes de código aberto.

Existem outras opções, JIRA, etc., mas elas (IMHO) não fornecem a facilidade ou a riqueza de funcionalidades que o fork do ChiliProject do Redmine + a infinidade de plugins disponíveis. Não há muito o que o Github e / ou o BitBucket façam por você que o ChiliProject (possivelmente com plugins disponíveis gratuitamente) não possa fazer; e a beleza é que, se ela ainda não existe, geralmente é bastante trivial implementá-la.

Se isso soa como mais do que você precisa ... Eu ainda não tentei, mas o GitLab também parece interessante ... não parece ter a arquitetura de extensibilidade ou plug-in do Redmine / Chili, mas se você estiver procurando para um clone de código aberto do Github com a maioria dos recursos principais (e você não precisa suportar vários DVCSs), parece muito bom.


Além disso, se você precisar de ferramentas de gerenciamento de controle de fonte baseadas na Web ... Usei com sucesso o Gitosis com Redmine / ChiliProject ... não tenho certeza do equivalente ao Mercurial, mas deve ser bastante trivial adicionar isso.
Jason Lewis

Atualização: O Redmine também usa versões atualizadas do Rails (se você quer dizer Rails 3) a partir do Redmine 2.
alternativa

7

Allura http://sf.net/p/allura deve caber na conta. É a plataforma para todos os projetos novos (ou atualizados) do SourceForge e é de código aberto. Ele suporta Mercurial e wikis, além de muitas outras ferramentas (Git, SVN, rastreador de tickets, fóruns, etc.). Ele não possui "revisão de código", mas suporta solicitações de bifurcação e mesclagem para repositórios Mercurial e Git.

É escrito em Python e usa MongoDB e Solr para armazenamento de dados.

Allura também está atualmente na Incubadora Apache: http://incubator.apache.org/projects/allura.html

Trabalho para o SourceForge e ajudo a desenvolver o Allura.


6

Para exatamente o mesmo problema no trabalho, usamos um ecossistema composto por:

  • Redmine para rastreamento de problemas
  • RhodeCode para gerenciamento de repositório
  • Jenkins para integração e implantação contínuas (temos trabalhos para tarefas de implantação e atualização que podem receber permissões granulares e você obtém a trilha de auditoria gratuitamente)
  • Active Directory para autenticação (todos os itens acima podem ser integrados a ele sem problemas)

A integração do DVCS no Redmine melhorou aos trancos e barrancos nas versões posteriores, atualizei algumas semanas atrás e estou extremamente satisfeito por a maioria das "dicas" desaparecerem.

Eu executo os servidores Redmine e RhodeCode no mesmo host porque o Redmine ainda não suporta repositórios de HG remotos. Jenkins é executado em vários outros hosts.

Eu uso um gancho RhodeCode para acionar puxões mercuriais no Redmine. Não posso usar um gancho para puxar Jenkins por causa do JENKINS-13717 , mas já enviei um patch para isso e acho que ele será aceito rapidamente. Enquanto isso, apenas pesquiso os repositórios de HG a cada poucos minutos.

Tudo é executado no Debian 6.0 sobre proxy reverso Nginx para obter a terminação SSL (tudo isso é usado apenas sobre SSL). Recentemente, todo o pacote foi movido para um cluster ProxMox para virtualizar tudo com ótimos resultados até o momento. Caso você não conheça o produto, dê uma olhada nele. É um daqueles " Eu não acredito que isso existe e eu não sabia disso e OMG também é de código aberto! ". Executamos esses serviços em contêineres OpenVZ que são facilmente migrados de um host para outro para reparos / atualizações de hardware. No mesmo cluster, também executamos várias máquinas virtuais KVM para testes automatizados em plataformas Windows.

Estou extremamente feliz com este ecossistema. Ele melhorou a capacidade da nossa equipe de desenvolvimento / controle de qualidade de reproduzir problemas e rastrear alterações por uma enorme margem. Apenas alguns avisos:

  • Se você usa o Rhodecode, não o configure no SQLite. Use MySQL ou outro DBMS real. Não é realmente migrável após o fato, e o SQLite leva apenas 1 conexão por vez, resultando em bloqueios engraçados e tempos limite (consulte o nº 439 do RhodeCode ). Isso se torna doloroso se Jenkins estiver pesquisando continuamente o repositório, à medida que você recebe mensagens de erro de vez em quando (veja o comentário acima sobre o problema de Jenkins).
  • Você realmente não pode enfatizar o suficiente para seus desenvolvedores que, no Mercurial, o número de confirmação "132" não significa nada para todos os demais na rede, pois esses números são apenas locais . Ao falar sobre conjuntos de alterações nos tickets do Redmine, use o número de revisão local que você pode obter no navegador de repositório (que é o mesmo no RhodeCode e no Redmine, já que eles são executados na mesma máquina) ou use commit:abcd1234.

Não hesito em recomendar essa configuração, pois estou extremamente feliz com ela. Se você precisar de ajuda para configurar um serviço específico ou quiser dar uma olhada nos meus arquivos de configuração, não hesite em perguntar.


2

Dê uma olhada no cydra: https://github.com/mensi/cydra com suporte para

  • Subversão (HTTP)
  • Git (HTTP e SSH em porta separada)
  • Mercurial (HTTP)
  • Trac

Ele funciona em uma abordagem baseada em projeto, que permite criar um projeto e atribuir vários repositórios a ele (no máximo um repositório SVN). A autenticação é baseada em plugins individuais (nós a integramos ao nosso LDAP).

Nós o usamos para nossa plataforma de codificação https://code.vis.ethz.ch . No momento, não há suporte para a revisão de código, mas ele pode ser facilmente adicionado como um plug-in.

Não consigo postar capturas de tela porque não tenho reputação suficiente.


11
O projeto Cydra parece que mal começou há alguns meses atrás e não parece ter sido desenvolvido ativamente. Pode ser um pouco imaturo para mencionar.
R0MANARMY

Sim você está certo. Mas, se você quiser configurar algo como uma plataforma de hospedagem de código, poderá personalizar muitas coisas por conta própria.
Pascal

2

Considere usar o GitLab https://about.gitlab.com/, pois ele atende à maioria dos seus requisitos:

  1. Você pode instalá-lo no local
  2. É MIT expat licenciado
  3. Possui wiki (suportado pelo git), navegação no repositório, gerenciamento de acesso detalhado (vários níveis de acesso, ramificações protegidas, integração ldap etc.) e possui solicitações de mesclagem para revisão e discussão de código (incluindo comentários de linha)
  4. Não suporta mercurial, mas apenas git

Ele também possui um bom rastreador de problemas ou você pode vincular a um rastreador de problemas externo. Você pode testar suas solicitações de mesclagem com o GitLab CI, se desejar. O GitLab tem crescido rapidamente e está sendo usado por mais de 25.000 organizações.

Divulgação: Sou o CEO e co-fundador da GitLab BV

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.