Visão geral

O participa.br é composto por 6 servidores. O mesmo utiliza um esquema de pastas públicas montadas via NFS, ou seja, tudo fica em uma mesma pasta. Um dos servidores tem por função realizar o balanceamento de carga para os demais servidores, nele encontram-se vários serviços que o participa utiliza (como exemplo, peerwise e virtuoso).

Processo de deploy

O SERPRO possui um servidor interno de homologação interno que é todo mantido em CentOS e um servidor de produção que utiliza o Debian. O SERPRO, de forma geral, adota uma política na qual o CentOS é utilizado em seus ambiente, isto faz com que o ambiente de produção do participa configure uma exceção. Contudo existe a possíbilidade de que a qualquer momento, seja exigida a mudança.

Para realizar a atualização dos ambientes utiliza-se o capstrano. Contudo, algumas funcionalidades não são configurados automaticamente pelo capstrano como o próprio NFS (este possuí um script próprio).

Basicamente o processo de desenvolvimento até o deploy consiste em:

1. Verificar se a nova funcionalidade pode ser desenvolvida a partir do master do noosfero (maioria dos casos);
2. Encorporar as alterações no master do noosfero.
3. Adiciona na versão do SERPRO;
4. Adiciona a nova funcionalidade em homologação. Valida com alguém, ou a própria equipe valida;
5. Após a validação em homologação, leva-se as novas funcionalidades para a produção.

Algumas vezes é preciso realizar atualizações com base na própria versão do noofero utilizado pelo SERPRO.

Informações gerais

Segue algumas informações gerais:

1. Noosfero roda no Apache 2.2
2. O código que roda em produção pode ser encontrado em: https://softwarepublico.gov.br/gitlab/noosferogov/noosfero
3. Descrição das branches pricipais:
   1. Production: Código que está sendo executado em produção;
   2. Staging: Código que está sendo executado em homologação;
4. A públicação é feita com o RVM.
5. Rotina de automatização de backups. Fora do controle deles, ninguém sabe a política.