relatorioR4.md 37.7 KB

RELATÓRIO DA RELEASE 4

Ações programadas para a Release 4, de acordo com o plano de trabalho:

  • Estudos de Evolução de plataforma integrada de colaboração
  • Protótipo de Ferramenta de Redes Sociais
    • Evolução do Núcleo Portal
    • Avalia SPB
    • Mercado Público
    • Subportais
  • Estudos de Evolução de plataforma de Integração
  • Estudos sobre Proxy de integração
  • Estudos sobre o sistema de Indexação de Buscas
  • Estudos sobre sistema de Ranking (gameficação)
  • Estudos sobre a evolução de serviço de Chat
  • Estudos sobre a Evolução do Sistema de Lista de e-mails
  • Estudos sobre a evolução de PAD colaborativo
  • Estudos sobre a Evolução de camada de back end (SO, plugin, integração)
  • Estudos sobre a Evolução do Sistema de Controle de Versão
    • Evolução de ferramentas de controle de versão
    • Evolução de ferramentas forge
    • Evolução de ambiente de monitoramento de métricas de código-fonte
  • Estudos Avançados sobre Migração
  • Estudos sobre documentação e comunicação multimídia do projeto
  • Estudos Avançados sobre a Evolução do Sistema de Identidade Visual
  • Estudos Avançados sobre a Evolução da estrutura de IHC
  • Estudos Avançados sobre a Evolução da Arquitetura da Informação
  • Estudos sobre a Evolução da superfície da interface gráfica do portal
  • Estudos para validação e análise dos protótipos com usuários
  • Estudos sobre licenças de software livre

Alinhamento Estratégico

Em reunião, realizada dia 13 de maio de 2015, com o comitê estratégico do projeto, liderado pelo diretor da DEGSI, Wagner Ribeiro, foram definidas as seguintes metas estratégicas para a release:

  • Alcançar maior número de Cidadãos
  • Disseminar o Software Não Público na APF
  • Quantificar economia (em R$) por parte do Governo com o uso do SPB

Nesta reunião foi explanado pelo diretor Wagner Ribeiro que uma das principais metas para o ano de 2015, em relação ao projeto, é disseminar e disponibilizar a plataforma do portal do software público (SPB) para o maior número possível de órgãos e entidades da Administração Público Federal. Para tanto essa meta compreende, no que diz respeito a plataforma do SPB, as funcionalidades relacionadas ao software não-público, até então nominado de software de governo. Um e-mail com ata da reunião foi enviado aos participantes (e está anexo a este relatório).

Com tais metas definidas em nível estratégico, as analistas da DEGSI/SLTI, Marisa Santos e Nayanne Bonifácio, juntamente com todo o time da UnB, estiveram reunidos no dia 18 de maio, onde foi realizado o planejamento desta release. Nesse sentido, a partir das metas estratégicas foram definidas as seguintes "épicas" para organizarmos as histórias de usuários e tarefas, conforme a metodologia apresentada no plano de trabalho do projeto:

  • Negócio
    • Disponibilizar Software de Governo
    • Migrar/Desligar Portal SPB Atual
    • Relato de Uso de Software
  • Técnicas
    • Integração de Perfis de Comunidades
    • Implantação da Release 4
    • Dívida Técnica
  • Não-Técnicas
    • Realizar Estudos de Licenças (minuta de alteração da IN01)
    • Treinamento/Suporte/Governança
    • Lançamento da campanha SPB (ASCOM) [Atribuição da SLTI e DTI]

Fase de Execução

Estudos de evolução de plataforma integrada de colaboração

Esta macro atividade, em relação a release 4, esteve associada a duas épicas. A primeira épica está detalhada a seguir:

  • Disponibilizar Software de Governo para o maior número possível de entidades da Administração Pública Federal.

A partir do detalhamento da referida épica, foram desenvolvidas as seguintes funcionalidades:

  • Criar Página de Software de Governo: proposta de Design
  • Modificar Filtro do Catálogo de Software
  • Disponibilizar o SEI na plataforma
  • Evoluir o catálogo de software para adicionar software de governo

A seguir é descrita a outra épica envolvida nesta macro atividade durante a release 4:

  • Relato de Uso de Software para proporcionar uma interação dos gestores, líderes de comunidades e usuários que poderão compartilhar suas experiências com o software, bem como estimativas de pessoas impactadas e valores economizados.

A partir do detalhamento da referida épica, foram desenvolvidas as seguintes funcionalidades:

  • Projeto do Relato de Uso
  • Envio de Relatos
  • Criação de avaliação para comunidades
  • Visualização de Relatos Simplificado
  • Moderação de Relatos e Notificação
  • Contador de Relatos
  • Criação de bloco de estatística/métricas de software

Protótipo de Ferramenta de Redes Sociais

Esta macro atividade, em relação a release 4, esteve associada às mesmas atividades executadas na macro atividade Estudos de evolução de plataforma integrada de colaboração.

Destaca-se aqui o desenvolvimento das funcionalidades relacionadas à épica Relato de Uso de Software onde foram trabalhadas novas interações sociais sobre comunidades de softwares a partir de avaliação e comentários sobre o uso do software.

Além disso, demandas do MP acrescentadas durante a release 4 também foram tratadas dentro dessa macro atividade, uma vez que estavam relacionadas à comunicação com usuários na plataforma de rede social. Destacam-se as seguintes funcionalidades:

  • Bloco "Veja Também"
  • Criação de Notificações flexíveis para comunicação dentro do ambiente
  • Moderação para deletar comunidades
  • Melhorias na ferramenta de fórum dentro da ferramenta de Rede Social

Estudos de Evolução de plataforma de Integração

Esta macro atividade, em relação a release 4, esteve associada as seguintes épicas:

  • Integração de Perfis de Comunidades.

A partir do detalhamento da referida épica, foram desenvolvidas as seguintes funcionalidades:

  • Definir Entidade de Comunidade:
  • Definir Mecanismo de Controle de Grupos para Plugins do Colab
  • Definir Protocolos de Comunicação entre Ferramentas
  • Implementar Modelo de Dados do Noosfero no Colab
  • Definir Mecanismos de Integração Visual (Dashboard)

As evoluções decorrentes dessa macro atividade foram acompanhadas pelas evoluções das ferramentas utilizadas no Portal, como Noosfero, GitLab e Mezuro.

Estudos sobre Proxy de integração

Esta macro atividade, em relação a release 4, esteve associada as mesmas atividades relacionadas à macro atividade Estudos de Evolução de plataforma de Integração. Contudo, adicionalmente foram estudados e tratados os problemas de segurança do Proxy de Integração.

Estudos sobre o sistema de Indexação de Buscas

Esta macro atividade, em relação a release 4, esteve associada as mesmas atividades relacionadas à macro atividade Estudos de Evolução de plataforma de Integração.

As evoluções das ferramentas integrantes do Portal, assim como dos plugins de integração de cada uma delas, apoiam a evolução da indexação de buscas na plataforma de integração, uma vez que os modelos de dados das ferramentas já estão representadas na plataforma, o que permitirá a evolução do Colab para um barramento de camada de aplicação.

Estudos sobre sistema de Ranking (gameficação)

A partir da Revisão de Escopo do projeto, explicada em uma seção posterior, este item foi modificado para que fosse possível atender outras demandas inerentes à evolução do projeto. Entretanto, a implementação da épica Relato de Uso de Software tem como consequência a criação dos insumos necessários para classificação das comunidades dos softwares e ainda está alinhada com os objetivos dessa macro atividade.

Estudos sobre a evolução de serviço de Chat

A partir da Revisão de Escopo do projeto, explicada em uma seção posterior, este item foi modificado para que fosse possível atender outras demandas inerentes à evolução do projeto.

Estudos sobre a Evolução do Sistema de Lista de e-mails

Esta macro atividade, em relação a release 4, esteve associada a seguinte épica:

  • Integração de Perfis de Comunidades.

A partir do detalhamento da referente épica, foram desenvolvidas neste contexto melhorias de back end relacionadas à comunicação entre a Plataforma de Integração e a ferramenta de Listas de e-mails. Em termos funcionais, essa evolução possibilitou a criaçao da seguinte funcionalidade durante a release 4:

  • Moderação de Listas de e-mail através da Plataforma de Integração

Estudos sobre a evolução de PAD colaborativo

A partir da Revisão de Escopo do projeto, explicada em uma seção posterior, este item foi modificado para que fosse possível atender outras demandas inerentes à evolução do projeto.

Estudos sobre a Evolução de camada de back end

Esta macro atividade, em relação a release 4, esteve associada a seguinte épica:

  • Integração de Perfis de Comunidades.

A partir do detalhamento da referente épica, foram desenvolvidas neste contexto as seguintes melhorias de back end:

  • Definir Entidade de Comunidade
  • Definir Mecanismo de Controle de Grupos para Plugins do Colab
  • Definir Protocolos de Comunicação entre Ferramentas

Estudos sobre a Evolução do Sistema de Controle de Versão

Esta macro atividade, em relação a release 4, esteve associada a seguinte épica:

  • Integração de Perfis de Comunidades.

A partir do detalhamento da referente épica, foram desenvolvidas neste contexto as seguintes melhorias de back end:

  • Definir Entidade de Comunidade
  • Definir Mecanismo de Controle de Grupos para Plugins do Colab
  • Definir Protocolos de Comunicação entre Ferramentas

Em relação a esta macro atividade, a evolução das atividades listadas teve como consequência uma maior aderência e integração das ferramentas e serviços relacionados ao Sistema de Controle de Versão com o restante da plataforma.

Estudos Avançados sobre Migração

Durante a release 3, realizamos um estudo de avaliação, com interações para alinhamentos com as analistas da DEGSI/SLTI, que resultou em um parecer técnico enviado a DESGI/SLTI com as recomendações para migração de conteúdos, bem como os motivos para a sugestão de recadastramento por parte dos usuários do antigo portal que desejam usar a nova plataforma do SPB.

Assim, a partir do detalhamento da épica Migrar/Desligar Portal SPB Atual, decidiu-se que na release 4 seriam migrados os conteúdos de Blogs e Fóruns do antigo portal. Portanto, as seguintes atividades relacionadas à migração dos conteúdos das comunidades existentes no antigo portal do SPB foram realizadas:

  • Migrar Comunidades
  • Verificação de Migração e Templates
  • Migração de Conteúdos (Fóruns e Blogs)

Após testes realizados em ambientes de Desenvolvimento e Homologação, a migração dos conteúdos foi realizada no ambiente de produção no dia 10 de setembro de 2015 com sucesso.

Documentação e comunicação multimídia do projeto

Esta macro atividade, em relação a release 4, esteve associada a seguinte épica:

  • Lançamento da campanha SPB (via ASCOM) para aumentar a publicidade de notícias relacionadas a plataforma

A partir do detalhamento da referida épica, foram desenvolvidas as seguintes atividades:

  • Cadastrar 70 softwares no catálogo
  • Mudar o DNS de beta para portal.softwarepublico.gov.br
  • Notificar usuários
  • Implantar R3 no ambiente de produção
  • Mudar o DNS de portal para softwarepublico.gov.br

As tarefas relacionadas a esta macro atividade, durante a Release 4, foram prioritariamente realizadas pela equipe da DEGSI/SLTI.

A equipe da UnB realizou uma atividade de mentoring executando a atividade de implantação da release 3 nos ambientes do MP, transferindo conhecimento para a equipe da DTI/MP.

Estudos Avançados sobre a Evolução do Sistema de Identidade Visual

A identidade visual do Portal evoluiu em diferentes áreas. Novos elementos gráficos e estilos foram criados, implementados e validados. Destacam-se os seguintes itens:

  • Design e estruturação do Relato de uso
  • Evolução visual e estruturação do Bloco de Métricas nas páginas de softwares
  • Reestruturação dos arquivos e regras de CSS do tema
  • Aplicação de estilos nas páginas principal e internas das Comunidades
  • Evolução visual dos Cadastros de Software e Comunidade
  • Design e estruturação de janelas “Tooltip” e “Popover” para o Portal
  • Revisão de classes e HTML para blocos do plugin SPB
  • Refatoração do CSS para plugins SPB
  • Elaboração e formatação para o Mapa do Site
  • Revisão e validação visual das áreas implementadas para versão de lançamento

Algumas funcionalidades foram adicionadas ao longo da Release 4, por solicitação do Ministério do Planejamento. São elas:

  • Criação e aplicação do design para área “notificações” localizada na página inicial do Portal
  • Criação e aplicação do design para área “Veja também” localizada na página inicial do Portal
  • Modificação visual dos filtros na página interna Catálogo de Softwares

Durante a etapa final da Release 4, foi informado a necessidade de padronização do cabeçalho e rodapé de acordo com o manual proposto pela SECOM. Ambos os elementos foram estruturados no visual padrão solicitado, levando em consideração as peculiaridades do Portal.

A evolução do Sistema de Identidade Visual foi apresentada aos gestores do Ministério do Planejamento em reuniões periódicas.

Com a solicitação de itens extras, os estudos e prototipação do AvaliaSPB foi retirada da Release 4, conforme entendimento com a DEGSI/SLTI.

Estudos Avançados sobre a Evolução da estrutura de IHC

Esta macro atividade, em relação a Release 4, esteve associada as seguintes épicas:

  • Evoluir a experiência de usuário da área aberta do portal para que os visitantes percebam o SPB como um único ambiente.
  • Disponibilizar o Software de Governo para o maior número possível de entidades da Administração Pública Federal.

A partir do detalhamento da referida épica, foram desenvolvidas as seguintes funcionalidades:

  • Evolução dos filtros na página interna Catálogo de Softwares
  • Evolução da Página de Software
  • Prototipação da Página Software de Governo
  • Prototipação das páginas associadas ao Relato de uso
  • Prototipação UX do bloco “Notificações” na página inicial
  • Prototipação UX do bloco “Veja também” na página inicial
  • Levantamento das funcionalidades atuais do portal
  • Levantamento das funcionalidades do Mezuro
  • Prototipação inicial para unificação do Painel de Controle

Estudos Avançados sobre a Evolução da Arquitetura da Informação

Durante a release 4, consolidaram-se as decisões de arquitetura da informação tomadas na release anterior, sem modificações de estrutura.

Estudos sobre a Evolução da superfície da interface gráfica do portal

Esta macro atividade, em relação a release 4, esteve associada as mesmas atividades relacionadas à macro atividade Estudos Avançados sobre a Evolução do Sistema de Identidade Visual.

Estudos para validação e análise dos protótipos com usuários

A validação e análise ocorre por etapas, onde membros da equipe, gestores do Ministério do Planejamento e usuários relatam suas impressões e experiências de uso no Portal.

Estudos sobre licenças de software livre

Foi empreendida análise do parecer jurídico contratado e o subsequente desenvolvimento de respostas referentes às questões jurídicas do licenciamento de software, englobando os requisitos jurídicos para licenciamento de software livre, normas e leis tocantes à contratação de softwares e ao aprimoramento de software, a existência de jurisprudência em casos de infração de direitos autorais em combinações com GPL e a possibilidade legal de duplo licenciamento de softwares.

Foi realizada também análise quantitativa das respostas objetivas e análise textual de dados provenientes de consulta à comunidade interessada por meio do participa.br, que forneceu insumo para a extração de diversas conclusões, indicando, principalmente, que a comunidade envolvida tem preferência à aceitação de mais modelos livres de licença no Portal do SPB.

Revisão de Escopo do Projeto

Conforme estabelecido no plano de trabalho e evidenciado nas atividades práticas da produção, neste projeto são utilizados métodos ágeis e tradicionais no âmbito da gestão e métodos ágeis no desenvolvimento. Como preceito dos métodos ágeis, o escopo deve se comportar de forma variável em função das necessidades e mudanças do negócio. Essa nuance difere os métodos ágeis dos métodos ditos tradicionais de gerenciamento, onde normalmente o escopo é prescrito de forma detalhada e o foco da gestão, por exemplo, é garantir que haja o mínino de desvios do plano definido nas fases iniciais do projeto.

Tais características trazem uma dinâmica diferente na produção onde o usuário passa a ter um papel central na priorização das necessidades em função do valor observável por ele para o negócio.

Durante as releases 1, 2 e 3, ocorreu, como esperado, a variação do escopo de acordo com as prioridades estabelecidas pela equipe da DGSI/MP, bem como nos níveis estratégicos do projeto, fazendo com que fossem incluídos no escopo novas necessidades não mapeadas inicalmente.

Contudo, trata-se de uma situação de comum aprendizado entre as equipes da UnB e do MP, uma vez que: i) os normativos que celebram a parceria entre as partes são fundamentalmente estruturados em metodologias tradicionais; ii) a cultura organizacional da SLTI/MP também é arraigada em valores oriundos de metodologias tradicionais; iii) a cultura organizacional do LAPPIS/UnB é baseada em valores dos métodos ágeis e desenvolvimento das comunidades de software-livre e iv) no início desta release houve uma completa reestruturação no níves estratégico da DGSI/MP.

Nesse sentido: i) considerando as variações de escopo ocorridas nas releases anteriores; ii) dos desbobramentos administrativos relacionados à prestação de contas; iii) da necessidade de capturar os direcionamentos da nova composição no nível estratégico da DGSI/MP; e das mudanças ocorridas na equipe da UnB, relatadas nos relatórios das releases passadas, fez-se necessário uma discussão para acomodação e realinhamento do escopo (variável) considerando as três últimas releases planejadas para o projeto.

Com isso, no dia 3/9/2015, na quarta reunião estratégica desta release houve o alinhamento no nível estratégico sobre a variação do escopo, ocorrida na DGSI/MP. Já no dia 8/9/2015, houve outra reunião decorrente dessa estratégica, realizada no LAPPIS/UnB, onde foi discutido e acordado entre as partes os desdobramentos da revisão nos níveis tático e operacional.

A seguir é possível observar o cronograma inicialmente proposto:

'TO-DO - Inserir a figura do cronograma inicial'

Consolidando os entendimentos entre as equipes segue o novo cronograma do projeto que passa a vigorar até que haja necessidade de novo alinhamento entre a estratégia do negócio e time de desenvolvimento.

'TO-DO - Inserir a figura do novo cronograma'

É importante ressaltar que a revisão do escopo não altera o objeto, a duração e orçamento do projeto. Nessa visão o tempo e orçamento são fixos, restanto a
variação ao escopo, caracterizando-o assim como variável, porém definido. Além disso evidencia-se também a colaboração e confiança entre o cliente, DGSI/MP e time de desenvolvimento, LAPPIS/UnB, valores preescritos no manifesto ágil.

Por fim, tais entendimentos serão formalizados e protocolados via ofício a ser encaminhado à DGSI/MP no início da release 5.

Benefícios alcançados

Gerenciamento de tarefas do projeto na própria plataforma

O desenvolvimento e gerenciamento da Release 4 foi todo realizado dentro do próprio Portal do Software Público Brasileiro, onde utilizou-se o Gitlab como a principal ferramenta de gerenciamento de atividades e documentação. Utilizou-se os recursos integrados aos grupos e repositórios do Gitlab para apoiar o fluxo organizacional já estabelecido na Release 3, mantendo-se os níveis estratégico, tático e operacional.

Neste sentido, o principal meio de documentação e comunicação, tanto no nível estratégico quanto tático, se tornou a Wiki do Gitlab que está presente dentro do principal repositório de desenvolvimento do projeto. A proposta utilizada consiste de um conjunto de páginas Wiki que seguem a seguinte estrutura:

  • Release X: Página com os detalhes da release onde são apresentadas todas as épicas, suas funcionalidades e histórias de usuários. O backlog, ou seja, o escopo da release está listado nessa página.
    • Cronograma/Agenda: Página onde estão descritas as datas de reuniões e cerimônias que acontecem ao longo de uma Release.
    • Sprint N: Página com a documentação da Sprint N onde estão mapeadas todas as histórias de usuários que foram planejadas. Cada sprint possui sua própria página onde pode-se ter uma descrição dos objetivos principais da sprint, assim como a lista de links para as histórias de usuários.

Além disso, a Wiki é utilizada para documentar, entre outras coisas, os procedimentos da equipe de desenvolvimento e contribuições para os softwares envolvidos.

No nível operacional, são utilizadas as ferramentas issues (tíquetes) e milestones (marcos) do Gitlab. Para cada história de usuário criou-se uma milestone com título, descrição e pontuação (estimativa). Dentro de cada história de usuário é criado um conjunto de issues descrevendo as tarefas que devem ser feitas para o desenvolvimento completo de uma história de usuário. Desse forma, para cada história de usuário, o Gitlab fornece um kanban onde os desenvolvedores assumem tarefas e modificam seu status. Essa visualização ainda apresenta uma barra de progresso representando o quanto de uma história já está finalizada.

Ambiente de monitoramento de Código-Fonte

Durante a release 4, além da correção de defeitos encontrados, foram adicionados à plataforma Mezuro novos coletores para que sejam extraídas métricas de Python e Ruby. Além disso, os principais passos já foram dados para integrar a plataforma ao Portal do SPB, através da plataforma de integração Colab.

Portanto, durante a release 4, a plataforma Mezuro foi evoluída para suportar a tecnologia de autenticação única utilizada pelo Portal do SPB, possibilitando o desenvolvimento do plugin de integração do Mezuro com o Colab. Para complementar a integração básica da plataforma, também já foi projetado e desenvolvido a integração visual inicial necessária para unificação da experiência do usuário, bem como a importação de dados inicial do Mezuro para a plataforma integradora Colab.

Os últimos passos remanescentes para a integração inicial do Mezuro no SPB estão relacionados ao processo de instalação da plataforma, como o empacotamento da ferramenta e de suas dependências. Com esses passos de instalação concluídos, o foco do desenvolvimento será no suporte à linguagem PHP que é utilizada por muitos projetos que compõe o Portal do SPB.

A integração do Mezuro no portal do SPB viabilizará a coleta, monitoramento e interpretação da qualidade interna dos produtos de softwares disponíveis na plataforma. Essas informações serão subsídios para ranqueamento e classificação dos softwares disponibilizados no portal.

Separação do catálogo de software de governo

Nesta release houve a evolução da experiência do usuário quanto a busca por software. Para possibilitar ao usuário distinguir e filtrar o resultado do software buscado no escopo de Software Público e/ou Software de Governo, separou-se o catálogo de Software Público dos demais com uma opção de filtro por tipo. Este filtro permite ao usuário obter a lista de todos os softwares ou apenas de softwares classificados como Públicos.

Os softwares conhecidos como software de governo passaram a ser encontrados a partir do bloco de destaque de software não-publico, ficando disponível na homepage do portal. Este bloco, identifica e esclarece ao usuário o que são estes softwares e direciona o usuário ao catálogo de softwares apenas não-públicos de maneira simples e direta.

Migração/Desativação da operação do antigo portal do software público

Durante a release 4, todos os softwares públicos restantes foram criados dentro da nova plataforma. Posteriormente, as permissões de escrita no portal antigo foram extintas para a realização da migração dos conteúdos de Blogs (notícias) e Fóruns (dúvidas e discussões) do antigo portal foram migrados, via scripts de automação, para as respectivas comunidades, no ambiente de produção, com sucesso.

Ao fim da release 4, na sexta-feira dia 04 de setembro de 2015, aconteceu o lançamento oficial do Novo Portal do Software Público Brasileiro que foi acompanhado de uma campanha de comunicação em revistas e rádios que fomentam a utilização da nova plataforma do sítio. O chaveamento para o novo portal foi marcado pela troca para o domínio definitivo do portal: softwarepublico.gov.br

Minuta de alteração da IN01

Desenvolveu-se a minuta da nova Instrução Normativa, concentrando esforços na flexibilização do esquema de licenciamento. A redação foi adaptada também para o tratamento adequado do "software de governo". Também visou-se facilitar e incentivar a oferta de softwares no portal, desburocratizando a disponibilização de software no SPB por meio da retirada da obrigatoriedade de registro no INPI e da flexibilização em relação à indicação de coordenador(es) para as comunidades.

Automação das rotinas de implantação nos ambientes do MP

A evolução das rotinas e procedimento de implantação da plataforma nos ambientes do Ministério do Planejamento foi um dos principais benefícios obtidos como resultado da release 4. Dada a complexidade dos serviços e softwares envolvidos no Portal do SPB, uma nova sub-equipe foi composta para evoluir e amadurecer os procedimentos de implantação do projeto através da aplicação de técnicas de DevOps.

Essa evolução consistiu do empacotamento dos softwares e suas dependências para a plataforma utilizada nos servidores do Ministério (CENTOS 7), evolução da ferramenta para gerenciamento das diferentes máquinas e ambientes existentes (chake) e das receitas chef para a configuração dos serviços em cada máquina. Adicionalmente, os manuais de instalação e manutenção do portal foram melhorados e detalhados com o objetivo de tornar os procedimentos de manutenção do portal reprodutíveis por outras equipes, como a DTI/MP.

Possibilidade de push utilizando o protocolo HTTPS

A ferramenta de controle de forge possui duas formas de push: SSH e HTTPS. Apesar da forma mais recomendada para se realizar o push ser utilizando o protocolo SSH, restrições internas nas redes de diversos órgãos públicos inviabilizam a utilização deste protocolo.

Após a realização de estudos e testes o uso do protocolo HTTPS foi viabilizado através de uma configuração na conta de cada usuário:

  1. Faça login no Portal.
  2. Acesse o menu "Código > Perfil".
  3. Clique na seção "Password".
  4. Clique no link "Forgot your password?", localizado abaixo do campo "Current Password".
  5. Faça logout. É importe que o usuário esteja deslogado do Portal para o próximo passo.
  6. Verifique sua conta de e-mail. Caso o e-mail de reset de senha não se encontre na caixa de entrada verifique na caixa de spam.
  7. Clique no link disponível no e-mail recebido.
  8. Forneça a nova senha (de preferência utilize a mesma senha utilizada para acessar o portal).
  9. Para realizar um push utilize o comando: git -c http.sslVerify=false push https://softwarepublico.gov.br/gitlab/<repositório>.git (substituindo <repositório> pelo nome do seu repositório).
  10. Utilize o usuário e a senha recém criada para autenticar cada push.

A solução encontrada possui duas limitações que podem levar a uma experiência confusa para o usuário. A primeira é a possibilidade do usuário utilizar uma senha de push diferente da senha do Portal. A segunda é a obrigatoriedade da utilização do parâmetro -c http.sslVerify=false para a realização do push – que além de afetar a experiência do usuário pode colocar em risco a transmissão do código do computador para o Portal.

Apesar das limitações a solução viabiliza a utilização do Portal por órgãos que antes estariam limitados.

Implantação em ambientes de Desenvolvimento, Homologação e Produção

Foram criados 3 ambientes na infraestrutura da DTI:

  • Ambiente de desenvolvimento para que a equipe de desenvolvimento realize testes de novas funcionalidades ou de correções em um ambiente gerenciado pela DTI, replicando de fato o ambiente que existe em produção;
  • Ambiente de homologação, de modo que uma vez aprovadas pela equipe de desenvolvimento, as alterações realizadas no Portal do Software Público possam então ser homologadas pela equipe do Ministério. Este ambiente é gerenciado pelo próprio ministério;
  • Ambiente de produção, onde o Portal do Software Público é entregue para os usuários finais.

Todos os ambientes acima são gerenciados pelo SERPRO e se encontram em uma mesma nuvem, de modo que os ambientes de desenvolvimento e homologação possuem, inicialmente, as mesmas configurações de software que o ambiente de produção. Isto é importante para prevenção de imprevistos relacionados a configurações diversas, como por exemplo, regras de firewall.

Para garantir que as configurações de software permaneçam as mesmas, todas as alterações realizadas em qualquer um dos servidores são feitas com o uso de técnicas de entrega contínua, através do uso de receitas Chef (técnica avançada que permite sempre replicar uma série de passos), de modo que as mesmas receitas são executadas em cada um dos ambientes.

Dificuldades encontradas

Absorção das rotinas de automação e implantação por parte do MP

Os ambientes de Desenvolvimento, Homologação e Produção configurados e mantidos no MP são de responsabilidade da Diretoria de Tecnologia da Informação-DTI. Esta por sua vez possui, atualmente, contrato de terceirização com o fornecedor Central Tecnologia, Serviços e Comércio de Informática LTDA-Central TI, que é responsável pela execução das demandas da DTI. Durante os períodos de implantação de novas versões da plataforma nesses diferentes ambientes, a equipe da UnB se deslocou ao MP, executou as instalações presencialmente, com participação dos líderes técnicos remotamente, onde os procedimentos técnicos eram acompanhados pelas equipes da DTI e Central TI. Todos os procedimentos realizados foram automatizados e documentados, de forma que o manual de instalação/operação da plataforma foi atualizado. Em que pese a equipe da UnB tenha mantido atualizado o manual de instalação/operação, além de realizar a transferência de tecnologia para realização de tais procedimentos, ainda há uma forte dependência da equipe da equipe da UnB, por parte do MP, para execução desse tipo de atividade.

Monitoramento e intervenção técnica no ambiente de produção

Como forma de viabilizar as intervenções da equipe da UnB no ambiente de produção, com vistas à investigação de defeitos materializados neste ambiente, foi definido, por parte do MP, um procedimento para tal, uma vez que a equipe da UnB só possui permissão de acesso ao ambiente de desenvolvimento.

A extração dos logs foi automatizada no repositório de gerência de configuração do SPB, mas como a equipe da UnB não tem acesso ao sistema de produção, é necessário abrir um chamado para a DTI extrair os logs e copiá-los para uma localização temporária no ambiente de desenvolvimento.

Avaliamos que este procedimento não está adequado pelos seguintes pontos:

  • O tempo de resposta da DTI para as solicitações é demasiado alto. Se os logs solicitados não estiveram corretos -- como já ocorreu, de recebermos logs do mês anteiror ao que foi solicitado -- o tempo de resposta para obtermos a informação correta é ainda pior.
  • O acesso apenas aos logs de forma estática, sem acesso a informações "ao vivo" do sistema é menos efetivo para identificação e resolução de problemas.
  • Devido à dependência com relação à equipe da UnB relatada no item anterior, na prática até o momento a mesma teve que fazer todas as intervenções necessárias para identificações de gargalos e resolução de problemas no ambiente de produção.

Tempo despendido com a atividade de empacotamento

O empacotamento é uma atividade que tem como base um pacote contendo o código-fonte original de um projeto de software e tem como objetivo preparar pacotes binários (instaladores) para que o software possa ser instalado facilmente por diversos usuários finais de um sistemas. O empacotamento inclui, mas não está limitado, às seguinte atividades:

  • integração com serviços (e.g. servidores de aplicação) do sistema para que possam ser gerenciados utilizando as ferramenta padrão do sistema operacional;
  • gerenciamento de dependências, de forma que todos os pacotes necessários para o funcionamento de plataforma sejam instalados automaticamente em conjunto com os componentes principais;
  • integração de forma sustentável de customizações específicas do Portal do Software Público Brasileiro;
  • gerenciamento de atualizações, de forma que a instalação de uma nova versão seja feita corretamente na presença de uma versão anterior, e que o processo seja executado corretamente sem intervenção manual.

Esta atividade traz grandes benefícios aos usuários finais, uma vez que ao ser finalizada torna-se muito simples a instalação. Contudo, tal descomplicação envolve um certo custo na etapa de desenvolvimento. Como na release 4 tivemos uma nova composição do time de DevOps (responsável direto por tal atividade), a equipe teve uma certa difuculdade para superar a curva de aprendizado natural que envolve esta etapa.

Outro fator importante que influência em tal atividade é a dependência da mesma com as demais equipes, uma vez que o processo de empacotamento advém diretamente da finalização de todas as atividades por parte de todos os times. Além disto, ao se finalizar um pacote é preciso retornar para a equipe interessada e realizar um ostensivo trabalho de testes visando assegurar a qualidade sobre o mesmo.

Aumento contínuo de escopo e atrasos nos feedbacks da migração

Apesar do estudo e das especificações feitas previamente com o levantamento das necessidades e viabilidades do processo de migração, em inúmeros momentos tais especificações tiveram seu escopo expandido por novas demandas. Outra falha que trouxe um impacto negativo na execução da migração foram os diversos atrasos no feedback e validação de cada etapa por parte do MP. Ambos os problemas forçaram a execução de novos desenvolvimentos e correções sem tempo hábil para os devidos testes e validações. As consequências disso foram comprometimento do cronograma e a perda da qualidade geral da entrega final.

Dificuldade de acesso aos ambientes de homologação e produção para a migração

Por conta da dificuldade de acesso aos ambientes de homologação e produção para a realização tanto da preparação como do processo de migração em si, foi necessária a implementação de mecanismos muito mais complexos que garantissem a replicação criteriosa dos ambientes reais em um ambiente externo desacoplado para contornar problemas relativos à diferença desses ambientes. Essa dificuldade de acesso também prejudicou a realização de testes de estabilidade do sistema pós-migração.

Custos Incididos na Release 4

Total dos Custos

Durante esta release só houve execução financeira da rubrica 33.90.20, bolsas à pesquisadores, representando na prática que o orçamento foi consumido apenas na categoria mão-de-obra. Como não houve sensibilização financeira nas demais rubricas, a categoria outras despesas é apresentada sem valores monetários. A coluna colaboradores indica a quantidade de bolsistas envolvidos em cada módulo do projeto durante a release. Em valor executado, é possível obervar similarmente o custo sobre mão-de-obra envolvida. O total parcial condiz na agregação dos custos, dividido pela sua natureza, neste caso iguais ao total executado, o valor total gasto durante esta entrega. De acordo com a imagem do total dos custos, o custo consolidados desta releasea foi de R$ 360.150,00. A quantidade de bolsistas, por módulo, e seu respectivo custo segue reapresentada na tabela a seguir:

Módulo/Equipe Quantidade Membros Custo
Colab 12 R$ 76.375,00
Noosfero 11 R$ 84.875,00
DevOps 05 R$ 44.750,00
Design 06 R$ 42.000,00
Mesuro 02 R$ 22.400,00
Licenças 02 R$ 32.450,00
Coordenação 03 R$ 57.200,00

Custos Diretos(Bolsas) por Módulo/Equipe

Neste gráfico é possível observar a representação do percentual do custo da mão-de-obra incidido em cada equipe do projeto. A maior alocação de recursos encontram-se nas equipes do Noosfero(representado pela cor laranja), uma vez que grande parte das funcionalidades desenvolvidas são providas através desta ferramenta, e a equipe do colab(representado pela cor azul), que provê o canal de comunicação no qual as ferramentas possam ser conectadas.

Anexos

TO-DO

Por fim, tais entendimentos serão formalizados via ofício a ser encaminhado para a DGSI/MP no início da release 5.