This is a read only archive of pad.okfn.org. See the
shutdown announcement
for details.
spb-dev
Título: Ágeis, Software Livre e DevOps - Transformando o desenvolvimento de software para e no Governo Federal
Roteiro
- O que o SPB? Histórico, problemas e evolução (Paulo)
- Como estamos desenvolvendo o novo SPB
- Como aplicar práticas ágeis (e de bom senso) que mitigam alguns pontos que são variáveis até para times ágeis (Paulo)
- Como desenvolver lidando com uma estrutura tradicional sem atingir nossa equipe ágil de desenvolvimento (Paulo)
- Arquitetura do novo SPB (Terceiro)
- Principais ferramentas: Noosfero, Colab, GitLab, MailMan e Mezuro
- Automaçao de infra-estrutura
- Ambientes de Desenvolvimento X Teste X Produçao
- Como entregar ao Governo um ambiente complexo, mas automatizado para instalação, configuração, backups e atualizações, resultando em “dez páginas” de comandos auto-explicativos
Palestrantes:
- Antonio Terceiro
- Paulo Meirelles
Recomendado para quem tem interesse em:
i) Valores, princípios e práticas ágeis
ii) Desenvolvimento colaborativo e distribuído
iii) Software livre
iv) DevOps
Resumo:O software livre se caracteriza pela colaboração entre equipes e usuários heterogêneos. Inspirada nesse modelo, está sendo criada uma plataforma colaborativa para o Software Público Brasileiro, com mais transparência e eficiência no desenvolvimento de projetos de software do governo. Essa nova plataforma é baseada na integração de ambientes colaborativos, sistemas de controle de versão e de monitoramento da qualidade do código-fonte, e está sendo desenvolvida por uma equipe altamente heterogênea, aplicando métodos ágeis, DevOps e práticas de desenvolvimento distribuído de software. Disponibilizar um conjunto de ferramentas e melhorar a experiência do usuário é o que às equipes da UnB e USP estão fazendo em prol da transformação do desenvolvimento de software no Governo Federal.Descrição completa:A nova plataforma para o Software Público Brasileiro foi pensada para contemplar ferramentas que promovam a colaboração e a interação nas comunidades (por gestores, usuários e desenvolvedores) dos projetos, conforme as práticas usadas nas comunidades de software livre. Isso inclui listas de e-mail, fóruns de discussão, issue trackers, sistemas de controle de versão e ambientes de rede social. Para integrar as ferramentas e prover a autenticação única nos serviços da plataforma, um sistema web chamado Colab, que funciona como proxy reverso para os ambientes, está sendo evoluído. Em resumo, o Colab oferece a integração de busca, autenticação e apresentação, provendo um único ambiente ao usuário que tem em seu perfil algumas métricas de contribuições (e-mails para listas, inserções em wikis, cadastros de issue e commits nos repositórios). O Colab foi desenvolvido para o Interlegis (programa do Senado Federal). Por padrão, funciona integrado com o servidor de listas de e-mail GNU Mailman e utiliza o Apache Lucene Solr para a indexação dos conteúdos para as buscas. A partir de 2014, as ferramentas GitLab e Noosfero foram integradas ao Colab para compor o novo SPB.
O GitLab é uma plataforma de desenvolvimento colaborativo social integrada ao sistema de controle de versão Git. É o ambiente mais técnico: os repositórios dos projetos do SPB, com páginas wiki, issue tracker e mecanismos de controle de versão de código estão nele. O Noosfero é uma plataforma para rede social e de economia solidária que contém funcionalidades de gerenciamento de conteúdos (CMS), além de permitir a configuração das páginas de usuários e de comunidades de forma flexível. É o ambiente de maior interação com o usuário do SPB, desde os cadastros até o acesso às páginas dos projetos para download, leitura de documentação e contato com os responsáveis. O que foi desenvolvido até aqui está em uso (acessível pela URL: softwarepublico.gov.br) e já supera o antigo portal do SPB, criado em 2007, em muitos aspectos. A integração de todos esses ambientes, compondo um inédito sistema de sistemas web, dependeu (e depende) de muita inovação, em seu processo de gestão e produção, gerando um caso a ser compartilhado com quem se interessa por métodos ágeis, software livre e DevOps, na prática e com qualidade.
Público alvo:Desenvolvedores, arquitetos, líderes de equipe, gestores
Aprenderemos:
- Como aplicar práticas ágeis (e de bom senso) que mitigam alguns pontos que são variáveis até para times ágeis
- Como desenvolver lidando com uma estrutura tradicional sem atingir nossa equipe ágil de desenvolvimento
- Como entregar ao Governo um ambiente complexo, mas automatizado para instalação, configuração, backups e atualizações, resultando em “dez páginas” de comandos auto-explicativos
Experiência dos palestrante com o assunto:
A plataforma está sendo desenvolvida pelo Laboratório LAPPIS-UnB, em parceria com o CCSL-USP. Os mais 15 anos de experiência de Antonio Terceiro colaborando nos códigos de grandes projetos de software livre, como Debian, Twiki e Noosfero, somado aos 12 de anos de experiência do segundo autor nas comunidades de software livre, ao lado de um grande equipe de alunos da UnB e USP e profissionais vindos da comunidade software livre, resultaram em um projeto de alta complexidade, já em produção, em pouco mais de 1 ano de trabalho com o Ministério do Planejamento.
ANTONIO TERCEIRO: Sócio fundador da Cooperativa de Tecnologias Livres (COLIVRE) e bolsista do Laboratório Avançado de Produção, Pesquisa e Inovação em Software da Universidade de Brasília (LAPPIS/UnB), atuando como líder técnico no projeto de reformulação do Portal do Software Público Brasileiro. Possui Doutorado em Ciência da Computação pela Universidade Federal da Bahia (2012). É membro do projeto Debian e um dos principais desenvolvedores do projeto Noosfero.*
PAULO MEIRELLES: Professor e atual coordenador do Bacharelado em Engenharia de Software da UnB. Possui Doutorado em Ciência da Computação pelo IME-USP (2013). É pesquisador-colaborador do Centro de Competência em Software Livre (CCSL) e do Núcleo de Apoio às Pesquisas em Software Livre (NAP-SOL) da USP. Coordena a Evolução do Portal do Software Público Brasileiro, no LAPPIS/UnB, em uma parceria da UnB com o Ministério do Planejamento.
===
Pontos fracos:
1. Não temos ambientes de desenvolvimento para que a equipe possa testar de forma rápida as alterações. Precisamos de dois níveis de ambiente: Todo o ambiente do SPB como desenvolvimento e máquinas específicas com algumas das ferramentas (ainda precisamos discutir melhor como fazer isto)
2. Não temos um processo contínuo de entrega. (Manzo vai levantar uma discussao a fundo nisso)
3. Pontuação entre os times está parecendo desnecessário (quase um overhead). -> decisao dos coaches
4. Não temos um roadmap entre as equipes. responsabilidade dos coaches e plenos
5. Equipe sentiu a mudança repentina da centralização dos repositórios. Várias das decisões não foram compartilhadas. licença poetica do terceiro
6. OBS se mostrou um grande overhead na forma como usamos. Precisamos de alternativas. usar copr; fedora -> local
7. Faltou visibilidade para o seniors e mais proatividade. relatos Arthur, Athos e Melissa
8. Novos membros, sofreram com a entrada no projeto no fim da release. Precisamos, "blindar" os novos membros que entrarem no fim da release. Falar com Paulo -> mimimi T_T
9. Difícil acesso aos backups.
10. Não temos um esquema para por backups específicos de cada ferramenta. 9 e 10: hangout com athos p/ explicaçao das rotinas de backup e possivelmente servir/separar backups
11. Precisamos de mais workshops entre as equipes. coaches
Pontos fortes:
1. Equipe proativa.
2. Equipe dedicada e focada.
3. Colab voltou a desenvolver.
4. O time do Devops foi oficializado.
5. Equipes estão mais próximas.
6. A equipe está mostrando preocupação com a experiencia do usuário.
====
Release 5
Metas estrategicas:
- Sustentaçao do novo SPB pelo MP
- Interaçao do novo SPB com outros dispositivos
- Alcançar maior numero de cidadaos
- Acompanhar o processo de entrada e evoluçao da qualidade dos projetos
Epicas:
1 - Integraçao dos perfis de usuários
- -> Dashboard padrao + dados pessoais
-> Nao inclui admin
2 - Evoluçao da busca global
-> Listas
-> Noosfero
3 - Avalia SPB
- -> Estudo: Evoluçoes (?)
- -> Workflow: etapas/status/acompanhamento (colab?)
- -> Preparaçao para automaçao da criaçao do ambiente?
- -> "Automaçao" dos criterios da IN (nova)
4 - Mercado publico
- -> Perfil do Noosfero (organizaçao)
- * evoluir Instituiçoes do Noosfero (plugins SPB)
5 - API (integraçao com outras plataformas)
- -> Noosfero
- -> Dados para dispositivos moveis
- -> Preparaçao para federaçao
- -> Preparaçao para o novo front-end
6 - Monitoramento de Codigo Fonte
- -> Evolucao do Mezuro
- -> Integracao Mezuro-Colab
- *Perfis
- *Navegacao
- *Busca (R6)
- -> Integracao Mezuro-Gitlab
7 - Sustencao/automacão da manutencão da plataforma
- -> Integracao Continua (pacotes)
- ->Refatoracao (spec/script/container)
- -> Ambiente de teste e desenvolvimento
- ->Evolucao do monitoramento
- -> Noosfero -> Rails 4
Atualização GEPNET
----------------------------
74. Substituido por: adequação do cabeçalho e rodapé ao Padrão Funcional da SECOM
76. 90%
77. 70%
78. 50%
79. 50%
81. 100%
82. 80%
84 80%
85. trocar para prototipo de pagina de governo 100% (eles nao definiram se vai entrar software de governo, que vai estar explicito no portal, como nao esta explicito so foi prototipado), esperando definições da IN.
87. 100%
88. 80%
89. 80%
90. 100% só não está dentro do dashboard
91. 80%
92. 100%
94. 90%
95. 90%
100. 80%
101. 80%
Syslog (27/08/2015)
----------------------------
Sergio e Tada
Nao funcionou:
* Nginx precisa da versão 1.7.1 pelo menos
* Jamie Nguyen - j@jamielinux.com (dono do pacote no epel. solicitar update?)
* Gitlab (não suporta por padrão?)
* Noosfero
* PostgreSQL
OK:
* Colab (feito)
* Mailman (verificado)
* Mailman-API (verificado)
* Backups (verificado)
otimizaçoes necessarias no ambiente (27/08/2015)
------------------------------------------------
discussao entre seocam e terceiro
* parametrizar opçoes de desempenho usar funçao do número de cpus [terceiro]
* produção:
* gitlab: 8 workers [terceiro]
* colab: 16 workers [seocam]
* noosfero: 8 workers [terceiro]
* postgresql: reservar 75% da RAM e outras otimizaçoes [terceiro]
* incluir no colab suporte a timeout nas requisiçoes aos backends [seocam]
relatório sobre problemas de instabilidade no SPB (11/08/2015)
--------------------------------------------------------------
Raiz da causa do problema: o script de importação de dados que é executado
a cada minuto deveria algum tipo de trava para previnir que mais de uma
instancia dele seja executada simultaneamente. Por não possuir esta trava
vários processos estavam sendo executados, cada um com uma conexão aberta
com o banco de dados do colab. Quando esse número aumentava acima de um
determinado limite, o limite de conexões por usuário no banco de dados
era atingido. Durante este espaço de tempo, qualquer requisição recebida
que envolvesse acesso ao banco de dados do colab (todas, no caso de usuarios
logados, e uma boa parte, no caso de usuarios não logados) iria retornar um
"erro interno no servidor" (erro 500).
Para identificar o problema analisamos os processos em execução na máquina e
correlacionamos com os logs do colab. O número anormal de processos nos deu
a dica de que o problema poderia estar relacionado com algum limite sendo
exaurido e ao analisar os logs do colab encontramos erros informando que o
limite de conexões com o PostgreSQL havia sido atingido. O limite de conexões
com o banco não era a causa mas apenas um sintoma do problema e aumentar
as conexões serviria apenas como paleativo, por isso a importancia da analise
de logs dentro de um contexto.
A solução temporária foi desabilitar a tarefa agendada enquanto a correção não
for implementada. Com isso os dados do Gitlab deixarão de ser importados
temporariamente. Além disso os logs de erro do Colab serão enviados para um
servidor mantido por nós enquanto o servidor de monitoramento não estiver pronto.
Analizando os logs, notamos que de fato este erro, que era identificado como
"OperationalError" predominava em relação aos outros:
$ grep '^\w*Error:' colab.log | awk '{print $1}' | sort | uniq -c
37 AttributeError:
37 IntegrityError:
81 KeyError:
26 LocationValueError:
6 MaxRetryError:
17237 OperationalError:
45 SerialisationError:
12 TemplateSyntaxError:
2526 TypeError:
2786 UnicodeDecodeError:
488 XMLSyntaxError:
Além disso, também foi possível identificar com que frequência este erro acontecia
desde quando ele ocorreu pela primeira vez até o final dos logs que tínhamos disponíveis
para análise:
$ grep -A 2 remaining.*connection colab.log | grep 2015 | cut -d ' ' -f 1 | sort | uniq -c
1807 2015-07-25
221 2015-07-28
4691 2015-07-29
4735 2015-07-30
2114 2015-08-01
2868 2015-08-02
801 2015-08-03
plano para máquina de monitoramento (2015-08-10)
------------------------------------------------
# objetivo ideal
- syslog server
- interface pra servir logs do syslog (nginx + basic auth)
- munin
- sentry [postgres]
- cliente sentry colab
- cliente sentry noosfero
- cliente sentry gitlab
- cron: disparar ping entre as máquinas e logar os resultados
e.g. ping -c 100 host; falhar se perda > 0%
# curto prazo
- [terceiro] munin na maquina de monitoramento
- munin-node nos servidores
- plugin packetloss do munin
- [seocam ]configurar sentry no colab
(usando sentry server do sergio)
Investigação sobre desaparecimento da comunidade `cacic` - 2015-08-04
---------------------------------------------------------------------
Identificamos a seguinte entrada nos logs da aplicação:
- Started POST "/social/myprofile/cacic/profile_editor/destroy_profile" for 200.198.196.206 at 2015-07-30 12:06:50 -0300
Isso nos diz que algum dos administradores da comunidade a apagou conscientemente aproximadamente ao meio dia do dia 30 de julho, uma quinta-feira. Este usuário estava no IP 200.198.196.206, que segundo o serviço whois pertence ao SERPRO. O geoiplookup sugere que este IP fica em Brasília/DF:
$ geoiplookup 200.198.196.206
GeoIP Country Edition: BR, Brazil
GeoIP City Edition, Rev 1: BR, 07, Distrito Federal, Brasília, N/A, -15.783300, -47.916698, 0, 0
GeoIP ASNum Edition: AS10954 FEDERAL DE PROCESSAMENTO DE DADOS - SERPRO
Se solicitado ao SERPRO, eles poderão informar exatamente aonde está este endereço IP.
Os usuários que são administradores da comunidade cacic são:
portal.softwarepublico.gov.br/social/profile/cacicmaster
portal.softwarepublico.gov.br/social/profile/eduardosan
portal.softwarepublico.gov.br/social/profile/israell
portal.softwarepublico.gov.br/social/profile/marisa
Checklist de atualizaçao do dia 03/08/2015
=================================
- Verificar antes da atualização
- Fazer antes da atualização
- Database de Homologaçao deve ter sido refeita (zerada)
- Atualizasr/convergir ambiente de devel
- ...
- Fazer depoois da atualização
- Remover listas de discussão de testes
- Verificar se sistemas subiram autimaticamente depois de Reboot
- ...
Listas Privadas (30/07/2015)
======================
Lista Privada != Lista Inscrição Moderada
Lista privada = histórico disponível apenas para membros
Lista Inscrição moderada = Lista onde moderador precisa aprovar inscrições
Ambas configurações (privada/moderada) precisam ser feitas via interface administrativa do Mailman
Conferir/Garantir:
- OK - Se listas privadas são indexadas para o PostgreSQL
- OK - Se listas privadas são marcadas como privadas (flag)
- OK - Se ao alterar uma lista de pública para privada se a alteração é refletida no PostgreSQL (e vice-versa)
- OK - Que a interface não mostra mensagens de listas privadas para usuários deslogados
- Dashboard
- User Profile
- Dashboard de Grupos
- Plugin do SPB
- ?
- OK - Que a interface não mostra mensagens de listas privadas para usuário que não é membro dela
- OK - Que a interface sempre mostra mensagens de listas privadas para usuário que é membro dela
- OK - Que a lista privada está sendo exibida para inscrição desincrição
- OK - [mailman-api] Nunca mostrar mensagens nem permitir inscrição na lista mailman (ou outro nome definido pela MAILMAN_SITE_LIST): http://www.gnu.org/software/mailman/mailman-install/site-list.html
- OK - Mensagens de lista privadas nunca são mostradas na busca
Documentar modificações na Mailman-API
- URI / aceita parametros. Quais?!
Logs (06/07/2015)
================
Curto prazhangout ?o:
Syslog
- Configurar apps para logar usando syslog
- Todos Nginx
- Colab
- Noosfero
- Mailman-api
- Gitlab
- Mailman
- backups (rsnapshot)
- Rodar servidor syslog no reverseproxy
Nginx
- Configurar para servir logs usando basic auth
Próximo release:
- Servidor de monitoramento (monitor):
- Serviços:
- Sentry
- Postgres (para o Sentry)
- Munin
- Config:
- 2 CPUs
- 4 GB de ram
- 200 GB de disco
- IP real
Problemas de Certificado (06/07/2015)
==============================
- Os certificados emitidos pelo ICP-Brasil não são reconhecidos por todos navegadores.
- No primeiro acesso o usuário precisa aceitar no navegador que o certificado é inválido e adicionar uma exceção que permitirá que o usuário navegue no domínio do site.
- A Barra Brasil é carregada apartir de um script fornecido pelo site barra.brasil.gov.br que também precisaria que a exceção fosse adicionada mas como a requisição é feita por script os navegadores não dão está opção ao usuário. Como consequência a barra não é carregada.
- Para carregar a barra o usuário tem duas opcões:
- Acessar o site https://barra.brasil.gov.br e adicionar a excessão antes de acessar o SPB;
- Instalar os certificados raiz do ICP-Brasil em seu navegador.
social:
/var/log/nginx/noosfero.access.log
/var/log/nginx/noosfero.error.log
/var/log/noosfero/*
/var/log/rsnapshot
integration:
/var/log/nginx/colab.access.log
/var/log/nginx/colab.error.log
/var/log/nginx/mailman.access.log
/var/log/nginx/mailman.error.log
/var/log/nginx/gitlab.access.log
/var/log/nginx/gitlab.error.log
/var/log/colab/colab.log
/var/log/gitlab-shell/gitlab-shell.log
/var/log/gitlab/unicorn.stderr.log
/var/log/gitlab/unicorn.stdout.log
/var/log/gitlab/application.log
/var/log/gitlab/production.log
/var/log/gitlab/sidekiq.log
/var/log/mailman/smtp
/var/log/mailman/qrunner
/var/log/mailman/error
/var/log/rsnapshot
database:
/var/log/redis/redis.log
/var/lib/pgsql/data/pg_log/*
Reverseproxy:
/var/log/nginx/ssl-*.access.log
/var/log/nginx/ssl-*.error.log
==============
[email aos usuários em 26.06]
Olá usuários do Novo Portal do Software Público Brasileiro (SPB),
Finalizamos, no dia 24 de junho de 2015, última quarta-feira, a migração da nova versão do Portal do SPB para infraestrutura definitiva de produção no Ministério do Planejamento com o SERPRO. Também, realizamos a primeira atualização, depois da migração, mas pequenos detalhes ainda estão sendo ajustados para a próxima atualização, em julho de 2015.
Dessa forma, destacamos os seguintes pontos:
1- O domínio softwarepublico.gov.br ainda corresponte à antiga versão do Portal, que deverá ser definitiva migrada para a nova plataforma até agosto de 2015.
2- Um novo domínio está sendo utilizado para o acesso à nova plataforma: portal.softwarepublico.gov.br. O domínio provisário beta.softwarepublico.gov.br já foi configurado para ser rediecionado para portal.softwarepublico.gov.br.
3- Aos desenvolvedores de projetos, mesmo com o redirecionamento configurado, sugerimos que as referências aos repositórios do SPB sejam alteradas nos seus repositórios locais para apontar para o novo domínio. Isso pode ser feito utilizando o seguinte comando:
git remote set-url origin git@portal.softwarepublico.gov.br:<grupo_gitlab>/<repositorio_gitlab>.git
- * onde "origin" representa o nome do repositório remoto
- * e "<grupo_gitlab>/<repositorio_gitlab>" representa o caminho para o repositório Git dentro do novo SPB
- * exemplo: git remote set-url origin git@portal.softwarepublico.gov.br:cacic/cacic.git
- 4- Os serviços do portal, como rede social (Noosfero), repositório (GitLab) e as listas de discussão (MailMan), estão funcionando normalmente: o próprio novo portal está sendo desenvolvido usando ele mesmo como ambiente de desenvolvimento e comunicação.
Caso algum usuário tenha problemas ao tentar fazer login devido à migração, sugerimos os seguintes passos:
a- Tentar recuperar a senha e logar novamente com a senha recuperada
b- Tentar apagar os cookies do navegador e tentar logar novamente
Em caso de problemas, por favor, enviar e-mail para admin@softwarepublico.gov.br.
Informamos que, mesmo estando em estágio avançado, o que está em portal.softwarepublico.gov.br não é a versão final da plataforma ainda. O acordo de coordenação entre o Ministério do Planejamento (via DeGSI/SLTI) e a Universidade de Brasília (via o Laboratório da LAPPIS/UnB Gama) é até outubro de 2016. Assim, ajustes, melhorias e mais evoluções irão acorrer ao longo de 2015 e 2016, dentro dessa parceria.
Agradecemos a compreensão e a atenção de todos,
Equipe de desenvolvimento do Novo Portal do Software Público
===
Pendencias do Deploy do dia 12/06/2015
Não estão chegando e-mails enviados para as listasRedirecionamento de https://beta.softwarepublico.gov.br para https://portal.softwarepublico.gov.br/ (http funciona mas https não)Pedir para ao Leandro Almeida para abrir a porta 22 (tentar um simples telnet portal.softwarepublico.gov.br 22 da pra ver que a porta não está aberta)Downloads não funcionam -> Há links para o BETALinks específicos dos blocos de software apontam para o BETA. Se houver redirecionamento, não há problema com isso.
Colocar aviso dos serviços que não estão funcionando.
=====
Checklist para migraçao do Beta para ambiente de produçao do ministerio.
Quarta-feira 10/06/2015
- 14:00 - Notificar usuarios sobre a migraçao e congelamento do beta (congelamento Quinta a noite, Migraçao sexta de manha)
- 17:00 - Notificar desenvolvedores sobre congelamento da branch master de softwarepublico/softwarepublico e pacotes no OBS
Quinta-feira 11/06/2015:
- 9:00 - Notificar (novamente) usuarios sobre a migraçao e congelamento do beta as 17:00
- 17:00:
- - Congelar/desligar beta
- - Obter backups
- - Tornar backups acessiveis ao ministerio (pendrive? subir em um VPS? note que nao temos acesso a porta 22 do beta do ministerio)
Sexta-feira 12/06/2015
- 10:15:
- - Alterar arquivo de configuraçao para resolver listas.softwarepublico.gov.br no ambiente prod
- - Convergir ambiente de produçao
- - Copiar backups para host no ministerio
- - Restaurar backup
- - Apontar beta.softwarepublico.gov.br para portal.softwarepublico.gov.br no DNS
- - Redirecionar beta.softwarepublico.gov.br para portal.softwarepublico.gov.br no nginx
- 14:00:
- - Atualizar domino do noosfero para portal.softwarepublico.gov.br
- -- rake login:social SPB_ENV=prod
- -- cd /usr/lib/noosfero
- -- sudo -u noosfero bundle exec rails console production
- -- d = Domain.first
- -- d.update_attributes(name: "portal.softwarepublico.gov.br")
- -- exit
- - Apontar listas.softwarepublico.gov.br para o relay (DNS)
- - Verificar restauraçao do colab: checar se usuarios podem se logar com suas senhas
- - Verificar restauraçao do git/gitlab: checar repositorios, issues e testar pull/push
- - Verificar restauraçao do noosfero: verificar comunidades
- -Verificar restauraçao do mailman: acessar listas.softwarepublico.gov.br e verificar se as listas e seus archives estao presentes
- - verificar envio/recebimento de email para lista de discussão
Segunda-feira 15/06/2015
- - Notificar os usuários sobre finalização da migração. Orientando para testar e como reportar possíveis bugs/erros durante a migração. Já orientar como resetar senha e ou recuperar uma conta.
Quarta-feira 17/06/2015
- - 14:30: Atualização de ambiente de produção (release intermediária)
===
1- "Migração" intermediária para a campanha publicitário do SPB:
- Opção I : softwarepublico.gov.br cairá em um hotsite com os links dos dois portais
- Opção II: softwarepublico.gov.br redirecionará para www2.softwarepublico.gov.br e nesse endereço o usuário poderá retornar para o Portal Atual, pelo endereço: softwarepublico.gov.br/index.vuh2
- Mudar o nome beta para www2 no DNS (DeGSI e UnB)
- Colocar um banner/botão para o usuário “retornar” para o Portal Atual
- Mudar link do emblema Portal velho para index.vuh2
- Opção III: desligamento do atual, de acordo com o processo de migração a ser definido pelo Rodrigo Souto
2- Preocupação de front-end
- FEITO - Fazer template página de software enxuta (Marisa fazer uma software "não-migrado" modelo)
- Remover categorias e editar outras (Encaminhado e-mail para o Artur)
- Traduzir as categorias
- Traduzir catálogo
- Remover tarja de beta/fork-me
- Verificar menu superior (Secom)
- Remover o beta da logomarca
3- Melhorias para o caso do SEI
- Clonar um artigo
- Busca na página do software (Noosfero)
- Permissão por tópicos em fórum
- Migração do fórum
- Migração dos repositórios
===
<email_para_usuário_do_beta>
Prezados usuários da versão Beta do novo Portal do Software Público Brasileiro (SPB),
Como notificado anteriormente, instalamos uma nova versão do Portal recentemente. Nesta nova versão houve uma modificação na forma de autenticação do portal, de modo que todos os usuários deverão solicitar restauração de suas senhas, seguindo os seguintes passos, de modo a reaverem acesso às suas contas:
1) Em seu browser, navegue até https://beta.softwarepublico.gov.br
2) Clique em login, no canto superior direito da tela
3) Clique no link "esqueceu sua senha?" ("Forgot Password?")
4) Entre com seu email (previamente cadastrado na versão beta do novo portal) e clique em Resetar a Senha.
5) Voce deve receber um email com instruções para restaurar sua senha (verifique sua caixa de spam também).
Note que esta nova versão ainda pode sofrer instabilidade nos próximos dias, dadas as tarefas de migração e instalação de novas funcionalidades.
Mais uma vez agradecemos a colaboração de todos os usuários e a compreensão desde a disponibilização da versão beta do novo SPB.
Em caso de dúvidas, por favor, contactar admin@softwarepublico.gov.br.
Atenciosamente,
Coordenação do Portal do Software Público Brasileiro
</email_para_usuário_do_beta>>
<email_de_manutencao_para_usuário_do_beta>
Prezados usuários da versão Beta do novo Portal do Software Público Brasileiro (SPB),
Como é de conhecimento de todos, desde dezembro de 2014, estamos com a nova versão do Portal do SPB em testes (beta.softwarepublico.gov.br). Hoje, instalaremos uma nova versão do Portal, ainda "beta", para entrarmos na fase final de homologação, antes de implantarmos o novo Portal do SPB em sua infraestrutura definitiva, no Ministério do Planejamento. Dessa forma, a partir das 17h, desta sexta-feira, 24.04.2015, a versão beta do novo SPB entrará em manutenção, com retorno previsto para às 15h da próxima segunda-feira, 27.04.2015.
Aproveitamos para agradecer a colaboração de todos os usuários e a compreensão desde a disponibilização da versão beta do novo SPB.
Na segunda-feira, 27.04, enviaremos uma notificação a todos quando a versão beta do novo Portal do Software Público Brasileiro ficar online.
Em caso de dúvidas, por favor, contactar admin@softwarepublico.gov.br.
Atenciosamente,
Coordenação do Portal do Software Público Brasileiro
</email_de_manutencao_para_usuário_do_beta>>
BEGIN text_review
Gerência automática de instalação, configuração e atualizações do ambiente
Para a release 3, encontrou-se a necessidade de dedicar um time à infra estrutura do projeto com a finalidade de viabilizar e facilitar a implantação dos ambientes de desenvolvimento, testes, homologação e produção. Primeiramente foram identificadas as dependências de software necessárias para o funcionamento das plataformas utilizadas no portal. Algumas destas não estão presentes nos repositórios oficiais da distribuição GNU/Linux utilizada na DTI (CentOS) nem nos repositórios adicionais lá utilizados (EPEL - Extra Packages for Enterprise Linux). Tais dependências, juntamente com as plataformas utilizadas no portal (Colab, Gitlab e Noosfero), foram empacotadas no formato RPM ( RedHat Package Manager), utilizado pelo CentOS. Os pacotes gerados são mantidos em um repositório, de modo que, através da ferramenta yum (Yellowdog Updater, Modified), os mesmos possam ser facilmente gerenciados.
Embora a complexidade de implantação dos ambientes tenha sido reduzida com os empacotamentos mencionados acima, algum esforço considerável deveria ser empregado para a configuração das ferramentas instaladas. Considerando tal fato, decidiu-se utilizar a ferramenta Chef para a automação de todo o processo de implantação, onde se descreve através de "receitas" (scripts de configuração) o estado final desejado de cada uma das máquinas e a ferramenta nos assegura isso após a sua execução . Foram desenvolvidos receitas para a instalação e configuração totalmente automatizada das plataformas utilizadas, de modo que, após a entrega da release 3, a possibilidade de que a tarefa de implantação torne-se um empecilho técnico após a transferência de tecnologia seja drasticamente reduzida.
Por fim, para auxiliar o desenvolvimento local, a equipe optou pelo uso da ferramenta Vagrant, que gerencia máquinas virtuais com configurações similares às do ambiente da DTI.
END text_review
1# 03/07/14 a 12/02/15: Estudos para automatização, empacotamentos para RPM (CentOS/RedHat) e escrita de scripts
*primeiro commit disponível em https://beta.softwarepublico.gov.br/gitlab/softwarepublico/softwarepublico/commit/9ad67e97fcf34c1d2d56f86b2fddf5508cfa74b6
2# 19/02/15 a 04/03/15: testes em ambientes locais replicando VMs da DTI, testes de acesso no ambiente da desenvolvimento da DTI, ajustes e documentação do script Chef (/beta.softwarepublico.gov.br/gitlab/softwarepublico/softwarepublico/blob/master/README.md).
3# 05/03/15: revisão da Release 3 com a Marisa e a Nayanne (DEGSI/SLTI) com a equipe da UnB.
3# 06/03/15: Congelamento dos pacotes RPM e fechamento do script Chef.
4# 09/03/15: Instalação completa no ambiente de desenvolvimento da DTI, usando o script Chef.
5# 10/03/15 a 13/03/15: Configurações; testes da migração do beta/SPB da infra da UnB para o ambiente da DTI; e ajustes necessários.
6# 16/03/15 a 20/03/15: Sugestão para a DTI instalar ambiente em homologação.
7# 23/03/15 a 27/03/15: Sugestão para a DTI instalar ambiente em produção.
8# 30/03/15: Previsão de disponibilização da primeira atualização (DTI apenas executará o script chef para atualizar).
Épicas
=====
Negócio
-----------
1- Eu como lider de comunidade ou membro da SLTI
desejo gerenciar permissões de usuários, comunidades e seus respectivos conteúdos
para permitir a moderação quanto a disponibilização das informações da plataforma
2- Eu como designer
desejo evoluir a experiência de usuário da área aberta do portal
para que os visitantes percebam o PSPB como um único ambiente
3- Eu como membro da SLTI
desejo avaliar o arcabouço jurídico/administrativo acerca de licenças de software livre
para permitir que a adm. publica federal tenha governança sobre os software
Arquiteturais
------------------
4- Eu como desenvolvedor/arquiteto
desejo refatorar a ferramenta de colaboração
para que esta proveja acesso integrado e modular aos diferentes ambientes da plataforma
5. Dívida Técnica
=======
Features
=======
1.1. Controle de acesso aos conteúdos
- - Evolução das Opções de privacidade para blocos
- - Evolução das Opções de privacidade para artigos para seguidores
- - Resolução de bugs relacionados à privacidade de outros conteúdos
- - Criação de conteúdos públicos em perfis privados
1.2. Controle de permissões aos usuários
- - Refatoração de esquema de permissões do Noosfero (Doing)
- - Criação de novas permissões
1.3. Controle de acesso à comunidades
- - Criação de funcionalidade de visibilidade de perfis
- - Convite de membros para comunidades
- - Melhoria do tipo "privado"
1.4. Controle de acesso de listas do Colab
1.5. Implementação de "tipos de comunidade"
1.6. Integracão de privacidades entre Gitlab e Noosfero
2.1. Evolução e conclusão do Cadastro de Software
- - Melhorias no cadastro e edição
- - Adicionar novas opções de licenças
- - Evoluções gerais (TODO)
2.2. Evolução e conclusão do Cadastro de Comunidade
2.3. Evolução e conclusão do Cadastro de Instituição
2.4. Evolução e conclusão do Cadastro de Usuário
2.5. Evolução e conclusão das páginas secundárias da área aberta do Portal
- - Evolução de blocos relacionados a notícias
- - Contribuições gerais no frontend
2.6. Evolução do Catálogo de Software
- - Evolução Catálogo para filtro
- - Adição novos campos importantes para serem filtrados
- - Adição ordenação
- - Refatoração da busca: Desempenho e Ajax.
- - Implementação de melhorias relacionas ao filtro de categorias
2.7. Evolução da Página de Software
2.8. Prototipagem UX e implementação do controle de aos conteúdos
2.9. Prototipagem UX e implementação Controle de permissões aos usuários
2.10. Prototipagem UX e implementação Controle de acesso à comunidades
2.11. Prototipagem UX da Página de Comunidades
2.12. Integração dos menus
2.13. Prototipagem UX da ferramenta de controle de versão
2.14. Estudos iniciais de adequações de acessibilidade
2.15. Prototipagem UX painel de controle do Noosfero
4.1. Implementação para suporte à plugins do Colab
- - Plugin do Noosfero para fornecer dados
- - Permitir que plugins tratem seus próprios templates e URLs
- - Definição de interface padrão para implementação de novos plugins
4.2. Biblioteca de Autenticação Única (Gem usada no Gitlab,...)
- - Definição do protocolo relacionado ao 'remote-user-data'
- - Gem 'omniauth-remote-user' foi finalizada e já está disponível (rubygems)
4.3. Integração Inicial do Mezuro
- - Início do suporte a autenticação de usuários via omniauth (utilizar gem desenvolvida pela equipe)
4.4. Implementação para suporte à coleta de dados nas ferramentas
- - Definição da interface para importação de dados das ferramentas
- - Definição da interface para indexação de dados das ferramentas
- - Remoção de dependência de busca para o Dashboard e Profile (haystack)
- - Importação e indexação de dados do Gitlab
- - Importação e indexação de dados do Trac
4.5. Independência do Persona/Mozilla
- - Tornou-se configurável a utilização do Persona/Mozilla (default = autenticação via Django)
5.1. Finalização dos pacotes e validação dos manuais
- - Total de 17 pacotes RPM construídos (entre as ferramentas e suas dependências)
- - Automação do deploy de todo o ambiente (em desenvolvimento)
5.2. Pacote RPM do Noosfero
- - Pacote finalizado e disponível
EXTRA:
- - Tornou-se configurável os campos do profile do Colab relacionados a redes sociais (Twitter, facebook,...)
- - Criação de uma suíte de testes considerável para o Colab (anteriormente não existente)
- - Integração contínua
- - Adição de vários testes ao django-revproxy (responsável de alguns dos problemas identificados no Beta), chegando a quase 100% de cobertura
4.1. Parecer preliminar (Respostas escritório de advocacia)
4.2. Consulta a conjur/AGU (SLTI)
4.3. Consulta pública no Participa.br
4.4. Consulta direta aos usuários do SPB (participa.br)
4.5. Análise dos resultados das consultas (Relatório)
=======
Histórias
=======
Fase 2 da evolução da macro-arquitetura da informação do Portal (80%)
Adequação ao padrão da SECOM (50%)
Implementação para suporte à plugins do Colab (25%)
Controle de acesso aos conteúdos (10%)
Controle de permissões aos usuários (10%)
Dívida Técnica
--------------------
Evolução da página de software (80%)
Criação da página inicial beta do Portal (90%)
Tradução de módulos dos ambientes (40%)
Criação de páginas secundárias (70%)
Adequações de acessibilidade (5%)
Evolução/integração do cadastro de software (10%)
Evolução/integração do cadastro de instituição (20%)
Evolução/integração do cadastro de usuário (40%)
Evolução/integração do cadastro de comunidade (20%)
Evolução para integração dos mecanismos de autenticação entre os ambientes (30%)
Implantação do serviço de Browser-ID próprio (independência do Persona/Mozilla) (0%)
Suporte à implantação no CentOS 7.0 (99%)
Pacotes de instalação dos ambientes e de suas dependências (99%)
Design - Resumo
------------------------
Fase 2 da revisão da macro-arquitetura da informação
Evolução da micro-arquitetura de informação
Evolução da superfície da interface gráfica do portal
Avaliações de usabilidade
Evolução da página inicial e das páginas internas, notícias e busca catálogo
Evolução da página de software (e páginas associadas) v2
Versão 1 da página de comunidade (e páginas associadas)
Análise inical para integração da seção Repositório
Versão 2 do Guia de Estilo e organização de CSS
Padronizar interface atual
Edição de material de divulgação do SPB (vídeo)
Desenv - Resumo
-------------------------
Arquitetura de plugins do Colab
Mecanismos de coletas de dados e buscas
Módulo de autenticação independente entre ambientes
Controle de permissões e publicação de conteúdos (público/privado)
Aplicação contínua do design