Ao acompanhar a história do desenvolvimento de software, nunca tivemos tantas opções de frameworks, linguagens de programação, templates de projetos e ao mesmo tempo nunca falhamos tanto em alcançar o objetivo, que é atingir as expectativas de clientes.

Scrum Master¶

O Scrum Master é o responsável por ajudar todos os envolvidos na equipe de projeto, ele facilita as interações e ensina os stakeholders a utilizar o Scrum. Ele utiliza os seus conhecimentos e técnicas para lidar com as pessoas e ajudar o Product Owner e a equipe de desenvolvimento a se tornarem mais eficientes no seu trabalho. Relacione o time de Scrum Masters, que você pode trabalhar.

Observação: Ao selecionar o Scrum Master troque o emoji de não selecionado (☑️) para o selecionado (✅).

• Passe algum tempo com a equipe (incluindo proprietários de negócios) para ensinar, não contar, o verdadeiro valor da preparação do backlog e torná-la uma prática definitiva;
• Os líderes devem identificar componentes essenciais comuns; habilitar arquitetos corporativos fortes com perspicácia em negócios, risco e tecnologia; e conduzir revisões de projetos entre divisões.
• Incorporando a segurança ao seu processo de desenvolvimento de software, desde o design de código seguro até a incorporação da varredura de segurança no pipeline de CI/CD.
• Equilibrar velocidade de desenvolvimento, segurança (incluindo privacidade de dados) e a experiência do usuário;
• Desenvolver protótipos ou mockups iniciais permite que os desenvolvedores mostrem aos clientes como o produto real ficará após o desenvolvimento, eliminando, em última análise, equívocos em um estágio inicial.
• Um escopo bem delineado ajudará você a resistir à tentação de incluir novas tarefas que, embora pareçam relevantes, terão grandes impactos no prazo e no orçamento originais.
• Para combater o aumento do escopo, seja claro sobre o que “feito” parece para o produto mínimo viável antes de começar, então garanta que você mantenha um foco de laser em entregar, em pouco tempo, algo que corresponda muito bem a isso.
• É importante dividir os projetos em pedaços pequenos o suficiente para que o cronograma possa ser medido com precisão — e então adicionar um buffer para lidar com os problemas que inevitavelmente surgem.
• As equipes de desenvolvimento de software podem evitar surpresas desagradáveis ​​pedindo aos desenvolvedores que estimem seu próprio trabalho e, em seguida, identificando e gerenciando dependências entre os membros da equipe.
• As equipes de desenvolvimento de software podem evitar surpresas desagradáveis ​​pedindo aos desenvolvedores que estimem seu próprio trabalho e, em seguida, identificando e gerenciando dependências entre os membros da equipe.
• A equipe de tecnologia deve obter ampla contribuição durante o desenvolvimento de pessoas não técnicas para garantir que o produto seja intuitivo e entregue o valor desejado.
• Os projetos de software é não entender e/ou não considerar os requisitos não funcionais, como desempenho, escalabilidade, resiliência, monitoramento e testes de qualidade. Esses requisitos são tão críticos quanto os requisitos funcionais e comerciais para garantir que a experiência do usuário final atenda às expectativas.
• Alinhar-se com os “bons de ter” versus os “indispensáveis” no início do projeto garantirá que as tarefas certas sejam priorizadas, o orçamento geral e o cronograma possam ser honrados e ninguém seja desagradavelmente surpreendido no final.
• A integridade dos dados é o obstáculo mais estressante e comum ao manobrar um novo projeto de software.
• Motivo comum pelo qual os projetos de software falham é a falta de comunicação, cooperação e colaboração suficientes entre as equipes de produto e engenharia.

Arquitetura de Software¶

• O porquê é mais importante que o como;
• Toda escolha é baseada em trade-offs.

Acredito que o essencial de um software de sucesso passará por:

• Aplicação: Qualidade de código, teste, documentação, resiliência e performance farão parte deste arcabouço;
• Cloud: Utilização do poder da cloud para acelerar e modernizar a infraestrutura atual.
• Segurança: RCA, SAST, DAST
• Dados: Utilizar os dados já existentes dentro da organização para potencializar a geração e aprimoramento de informações de produtos dentro de uma organização.

Diferimento¶

Tipo de Projeto¶

DEVELOPER/FUNCIONAL¶

ERelacione os papéis de um Analista Funcional, que atua como intermediário entre as partes interessadas (stakeholders) e a equipe técnica, assegurando que os requisitos do negócio sejam bem compreendidos e implementados e um Developer, que é responsável por escrever, testar e manter o código de software. Eles transformam requisitos técnicos e funcionais em soluções programáticas.

ENTENDA O PROJETO¶

Além de entender o negócio, você precisa olhar para os Requisitos de Arquiteturais (RA) e os Variáveis Arquiteturais(VA).

Requisitos de Arquiteturais¶

O time deverá discutir o projeto, cada um seguindo a sua especialidade, arquitetura, riscos de segurança e automatização de teste.

Relacione os Product Owner/Manager e Stakeholders¶

Tipo de Servidores¶

Provedor Serviço em nuvem¶

Tipos de Serviços de Computação em nuvem¶

Tipo de Serviço¶

Ambientes Operativos¶

Controle de Atividades¶

Source Control Management¶

• Monolito

• Monorepo

Estratégias de Branch¶

Tecnologia Oracle¶

Generate REST APIs¶

Servidor de Aplicação¶

Front/Back¶

Low-Code Platform¶

Trace/Logs¶

Container¶

Gerenciadores de Banco de Dados¶

Documentação Produto¶

Documentação Técnica¶

Emulador¶

Framework¶

BPMS¶

Content Management System(CMS)¶

Containers¶

Framework de Teste Unitário¶

Code Coverage Tool¶

Framework de Teste¶

Framework de API/Contrato/Stress¶

Gerenciadores de Dependências¶

Maven Archtype¶

RPA¶

ETL/ELT/ELTT (Extract, Load, Transform, Transfer) Ferramentas¶

Exposição de Dados¶

Azure-Devops¶

Repository Management¶

Estratégia de Desenvolvimento¶

Escrita de Código¶

Convenções de Desenvolvimento¶

Preenchimento do Board/Timesheet¶

O lançamento de horas em um determinado projeto ou atividade, tem como finalidade melhorar a gestão de tempo ao registrar o tempo gasto para realizar determinada atividade. Utilizar o lançamento de horas traz mais transparência e precisão para a gestão de tempo, o que permite um melhor controle e monitoramento das atividades realizadas.

• Compreensão da rotina dos profissionais;
• Alocação eficiente da Equipe;
• Estimativa de Tempo médio para a realização de uma tarefa ou atividade;
• Maior assertividade nos prazos acordados;
• Melhorar a organização da equipe;
• Ter suporte para o planejamento;
• Tomar decisões baseadas em dados;

Sugere-se que o lançamento de horas seja realizada de forma diária e com 10 minutos antes de suspender e/ou finalizar as atividades diárias.

Code Review¶

• Pratique revisões pequenas de código;
• Cultura de qualidade;
• Boa documentação na base de código para manutenção(PLDoc,JavaDoc,PHPDoc)
• Discutão soluções alternativas;
• Guia de forma colaborativa;
• Mantenha um cronograma de Code Review

Cultura,Automação,Lean,Medição e Sharing¶

Segurança¶

Autenticação¶

• Não use Basic Auth. Use padrões de autenticação (exemplo: JWT, OAuth).
• Implemente funcionalidades de limite (Max Retry) e bloqueio de tentativas de autenticação.
• Limite as tentativas de , e Login APIs Verify One Time Password(OTP) para um usuário específico. Tenha um conjunto de espera exponencial ou/ou algo como um desafio baseado em captcha.
• Use criptografia em todos os dados confidenciais.

JWT (JSON Web Token)¶

• Use uma chave JWT Secret para tornar ataques de força bruta menos eficientes.
• Não utilize o algoritmo de criptografia informado no cabeçalho do payload. Force o uso de um algoritmo específico no back-end (HS256 ou RS256).
• Defina o tempo de vida do token (TTL, RTTL) o menor possível.
• Não armazene informações confidenciais no JWT, pois elas podem ser facilmente decodificadas.
• Evite armazenar muitos dados.

Acesso¶

• Limite a quantidade de requisições (Throttling) para evitar ataques DDoS e de força bruta.
• Use HTTPS no seu servidor para evitar ataques MITM (Man In The Middle Attack).
• Use cabeçalho HTTP Strict Transport Security (HSTS) com SSL para evitar ataques SSL Strip.
• Para APIs privadas, permita o acesso apenas de IPs/hosts da whitelist.

Requisição¶

• Utilize o método HTTP apropriado para cada operação, GET (obter), POST (criar), PUT(atualizar) e DELETE (apagar). Não esqueça as operações no e-BS.
• Valide o tipo de conteúdo informado no cabeçalho Accept da requisição (Content Negotiation) para permitir apenas os formatos suportados pela sua API (ex. application/xml, application/json ... etc), respondendo com o status 406 Not Acceptable se ele não for suportado.
• Valide o tipo de conteúdo do conteúdo da requisição informado no cabeçalho Content-Type da requisição para permitir apenas os formatos suportados pela sua API (ex. application/x-www-form-urlencoded, multipart/form-data, application/json e etc).
• Valide o conteúdo da requisição para evitar as vulnerabilidades mais comuns (ex. XSS, SQL-Injection, Remote Code Execution ... etc).
• Não utilize nenhuma informação sensível (credenciais, senhas, tokens de autenticação) na URL. Use o cabeçalho Authorization da requisição.
• Use apenas criptografia do lado do servidor.
• Use um serviço gateway para a sua API para habilitar cache, limitar acessos sucessivos (ex. por quantidade máxima permitida (Quota), por limitar tráfego em situações de estresse (spike arrest) ou por limitar o número de conexões simultâneas na sua API (Concurrent Rate Limit)), e facilitar o deploy de novas funcionalidades.

Processamento¶

• Verifique continuamente os endpoints protegidos por autenticação para evitar falhas na proteção de acesso aos dados.
• Não utilize ID's incrementais. Use UUID.
• Se você estiver processando arquivos XML, verifique que entity parsing não está ativada para evitar ataques de XML externo (XXE - XML external entity attack).
• Se você estiver processando arquivos XML, verifique que entity expansion não está ativada para evitar Billion Laughs/XML bomb através de ataques exponenciais de expansão de XML.
• Use Content Delivery Network(CDN) para uploads de arquivos, arquivos estáticos como fotos e vídeos para aplicações de modo mais rápido e eficiente.
• Se você estiver trabalhando com uma grande quantidade de dados, use workers e queues (fila de processos) para retornar uma resposta rapidamente e evitar o bloqueio de requisições HTTP.
• Não se esqueça de desativar o modo de depuração (DEBUG mode OFF).
• Use stacks não executáveis quando disponíveis.

Resposta¶

• Envie o cabeçalho X-Content-Type-Options: nosniff, onde o navegador é instruído a não tentar adivinhar o tipo de conteúdo do arquivo e deve seguir estritamente o tipo de conteúdo fornecido pelo servidor.
• Envie o cabeçalho X-Frame-Options: deny, impossibilitando que outros sites renderizem em um iframe.
• Envie o cabeçalho Content-Security-Policy: default-src 'none'.

  <meta>http-equiv="Content-Security-Policy"content="default-src 'self'; img-src https://*; child-src 'none';" />
  

• Remova os cabeçalhos de identificação dos softwares do servidor - X-Powered-By, Server, X-AspNet-Version.
• Envie um cabeçalho Content-Type na sua resposta com o valor apropriado (ex. se você retorna um JSON, então envie um Content-Type: application/json).
• Não retorne dados sensíveis como senhas, credenciais e tokens de autenticação.
• Utilize o código de resposta apropriado para cada operação. Ex. 200 OK (respondido com sucesso), 201 Created (novo recurso criado), 400 Bad Request (requisição inválida), 401 Unauthorized (não autenticado), 405 Method Not Allowed (método HTTP não permitido) ... etc.

CI & CD¶

• Monitore a especificação e implementação do escopo da sua API através de testes unitários e de integração.
• Use um processo de revisão de código, escolha o mais experiente para code review;
• Execute continuamente testes de segurança (análise estática/dinâmica) em seu código.
• Verifique suas dependências (software e sistema operacional) para vulnerabilidades conhecidas.
• Implemente funcionalidade de reversão de deploy (rollback).

Criação do Projeto¶

Esta rotina deverá ser executada em ambiente Linux/MacOS e deverá possuir os seguintes softwares instalados:

Ajustes no Azure-Devops¶

• Após a criação do PROJETO e/ou TIMES, há a necessidade em se IGUALAR os BOARDS.
• Acesse o Board do Time e efetue as seguintes alterações, em Boards → Columns:

• Limitar a WIP ao número de desenvovedores do PRODUTO;
• Ajuste Swimlanes
• Bug -

  Vermelho

• Demanda Expressa -

  Verde

• Projeto

• Boards → Configuração → Fields → Product Backlog → Additional Fields → Add Field → iSBlocked

Dashboard Team¶

Ajustes no Github¶

Pipeline - DevSecops¶

Teams (WebHook)¶

Registrar Produto¶

Gerenciamento da Identidade e Acesso¶

Provedor de Identidade (IdP)¶

Desevolvimento¶

Validação de Campos Utilizando Expressões Regulares¶

RegEx ou RegExp são usadas para englobar um padrão de caracteres usando alguns caracteres especiais.

Associe a validação do RegEx a um código de erro e grave o erro na tabela de mensagens, na lingua desejada.

Mensagens Padronizadas¶

• Mensagens serão divididas em n grupos:
  • Códigos de Status HTTP
  • Mensagens da Aplicação

Apresentação dos Membros do Projeto Autodescrição¶

Pré-Produção¶

Métricas¶

Definição das Métricas¶

Front-End: Core Web Vitals (Google)¶

Métricas de Dados¶

Métricas para Desempenho do Banco de Dados¶

A observabilidade do banco de dados também se estende ao desempenho do próprio banco de dados incluir:

Métricas para segurança de Banco de Dados¶

As medições de observabilidade do banco de dados podem colocar em foco a segurança e a conformidade do banco de dados, elevando o nível de segurança dos dados.

Documentação¶

Catálogo de Serviços¶

• Registrar a Aplicação no Catálogo de Sistemas Internos;
• Associar demanda do Catálogo de Sistemas Internos ao Projeto;
• Elaborado plano junto a area de segurança para realização/revogação de acesso;
• Elaborado documentação para Equipe de N1.

Segurança¶

Lei Geral de Proteção de Dados Pessoais (LGPD) e Acesso¶

Realização de OPT-In e OPT-Out para a Segurança?

API Security¶

• Testes de segurança - API(csaf report);

Application Performance Management/Monitoramento¶

Periodicidade de Clonagem¶

Complemente a Leitura¶

Modelo Base¶

A metodologia doze-fatores pode ser aplicada a aplicações escritas em qualquer linguagem de programação, e que utilizem qualquer combinação de serviços de suportes (banco de dados, filas, cache de memória, etc). Os contribuidores deste documento, possuem experiencia em desenvolvimento, operação através do seu trabalho na plataforma Heroku.

The Twelve Factors ou Fourteen Factors(*)¶

• Obviamente o 14 fatores NÃO existem no mercado, mas estava trabalhando para tal.
• Podíamos ter utilizado a suite SharePoint, OneDrive,Power Apps e Microsoft Forms, mas optei em utilizar um Static Site Generatir - MkDocs e fazer tudo como se fosse código.

Arquitetura Proposta¶

Já se foi o tempo em que todos os serviços eram gerenciados a partir de um único servidor ou local. Estamos vivendo a era de poder criar software em uma ampla rede de máquinas e software gerenciado por sua própria equipe ou por serviços externos. Este blueprint de serviços tecnológicos, permite a visualização, das relações entre diferentes componentes de software/hardware, estabelecendo caminhos a serem seguidos para a melhoria do atendimento e garantia da segurança.

Centralização de Logs¶

Configuração de Logs

Arquitetura Proposta Nomenclaturas¶

Projetos¶

Um projeto é um “esforço temporário empreendido para criar um produto, serviço ou resultado único” em uma organização. No entanto, para ser verdadeiramente competitiva, uma organização precisa ser capaz de fornecer um fluxo contínuo de mudanças. A estrutura define explicitamente um fim: um ponto em que o projeto será concluído.

Em vez disso, deve ser entendido que cada PRODUTO se destina a alcançar um ou mais resultados de negócios e, para isso, deve mudar e melhorar continuamente.

Padronize-se no Estilo hipster:

• Contribuição e Estilos
• Código de Conduta

Command Query Responsibility Segregation¶

É um padrão de arquitetura de software que propõe separar as operações de leitura (queries) das operações de escrita (commands).

• Responsibility Segregation (Segregação de Responsabilidades): Refere-se à ideia de que diferentes partes do sistema têm responsabilidades diferentes.
• Command (Comando): Representa uma ação que causa uma mudança de estado no sistema.Os comandos são usados para operações de escrita, como criar, atualizar ou excluir recursos.
• Query (Consulta): Representa uma solicitação de informações do sistema. As consultas são usadas para operações de leitura, como recuperar dados ou realizar operações de busca.

Oracle REST Data Services¶

É um serviço de dados baseado em Java Enterprise Edition (Java EE) que fornece segurança aprimorada, recursos de cache de arquivos e serviços Web RESTful, no caso da 60pportunities, optou-se na implantação com o uso de servidores Apache Tomcat.

Volumes Docker¶

Volumes persistentes no Docker são uma maneira de manter os dados dos containers mesmo após o container ser desligado ou excluído. Isso é especialmente útil para aplicações que precisam armazenar dados ou configurações que devem persistir entre diferentes execuções do container.

Estratégias de Branch¶

Consulte Material - Registro de Arquitetura Estratégia de Branch.

NÃO deixe de ler o material de Vincent Driessen sobre o modelo de ramificação git-flow, apresentada em sua publicação em 2010 e released em 2020.

Os aplicativos da Web normalmente são entregues continuamente, não são revertidos e você não precisa oferecer suporte a várias versões do software em execução.
Esta não é a classe de software que eu tinha em mente quando escrevi a postagem no blog há 10 anos. Se sua equipe estiver fazendo entrega contínua de software, sugiro adotar um fluxo de trabalho muito mais simples (como GitHub flow ) em vez de tentar encaixar o git-flow em sua equipe.

Diretório Pipeline¶

Quando se trata de organizar a estrutura de pipelines em um projeto, é importante manter uma organização clara e coerente que facilite a compreensão, manutenção e execução dos pipelines. Dentro de cada diretório de pipeline, há um arquivo pipeline.yml que descreve os passos e etapas a serem executados no pipeline correspondente. Além disso, pode haver outros arquivos ou diretórios conforme necessário para armazenar recursos ou configurações relacionadas a cada tipo específico de pipeline.

Documentos as Code¶

É uma abordagem na qual a documentação do projeto é tratada e gerenciada como código-fonte. Estruture o documento seguindo o modelo PORTIFÓLIO.

• Versionamento: A documentação é versionada e mantida EM um sistema de controle de versão, permitindo rastrear alterações, revisar históricos e identificar facilmente quem fez cada alteração.
• Colaboração: As mesmas práticas de colaboração e revisão de código podem ser aplicadas à documentação.
• Automatização: Ferramentas de automação podem ser usadas para gerar documentação a partir do código-fonte ou para atualizar automaticamente a documentação conforme o código é alterado.
• Testabilidade: A documentação DEVE SER parte do processo de integração contínua (CI).
• Implantação Contínua: A documentação DEVE SER implantada automaticamente em um ambiente de produção ou em um sistema de publicação sempre que houver alterações.

• Garante com isso Maior Consistência, Transparência, Facilidade de Manutenção, Melhor Colaboração, Agilidade e Redução de Erros.
• O projeto 60OPT_ADMISTRAÇÃO, possui um monorepo POROTIFÓLIO, e um diretório para cada documentação de PRODUTO, tornando o gerenciamento muito mais fácil.
• No repositório PORTIFOLIO, use o diretório documentacao e crie uma entrada utilizando o submodule, para cada produto a ser documentado.
• Caso o produto seja novo, ajuste o arquivo de DOCUMENTAÇÃO - mkdocs.yml, para incluir o seu submodule.

• Adicionando um repositório a Documentação, ao repositório 60OPT ADMINISTRAÇÃO no repositório PORTIFOLIO.

  • git submodule deinit --force backstage (excluir um submódulo Git)
  • git rm --force backstage (Remove the submodule directory from Git)
  • rm -rf .git/modules/backstage (Remove the submodule directory from .git/modules/)
  • git submodule add --name backstage https://github.com/P0010/mkdocs.yml.git backstage (Adiciono o submodulo)
  • Alterando o mkdocs.yml, para inclusão da Documentação
  • Vá até a entrada nav e procure o seu sistema.
  • '!include ./documentacao/APLICACAO/mkdocs.yml' 60opt-documento-produto

Estrutura padrão¶

Seguir o nodelo Nomenclatura de Repositórios de documentação - PRODUTO - FINALIDADE - ESTRUTURA. Verifique e ajuste o modelo de PORTIFÓLIO para a sua necessidade EXEMPLO.

 mkdocs-project/        Local do projeto onde estão todos os arquivos MkDocs.
      mkdocs.yml           Arquivo de configuração do Mkdocs.
      docs/                Pasta onde existem Markdown e outros arquivos de conteúdo.
        *.md               Arquivos em Markdown
        img/               Pasta contendo arquivos de imagens
          *.regex          Arquivos `^[^\s]+\.(jpg|jpeg|png|gif|bmp)$`
        objetos/           Pasta contendo o javadoc, godoc, plsqldoc ou phpdoc
          *.html           Arquivos gerados normalmente em html
        unitest            Pasta contendo informações sobre o resultado dos Testes Unitários
        moldb              Modelo de Dados
          *.html           Arquivos gerados normalmente em html
        allure             Arquivos de Testes
          *.html           Arquivos gerados normalmente em html
        swagger            Pasta contendo os arquivos json Openapi
          *.json           Arquivos extraídos do ORDS ou gerados pelo editor swagger
          index.md         Arquivo contendo uma página com as entradas dos JSON.
      site/                Pasta criada automaticamente pelo software MkDocs, quando build.
        index.html         Página de destino padrão para site estático.
        muitos outros arquivos Cada markdown virará uma pasta

• Exemplo de criação:

  .
  ├── README.md
  ├── docs
  │   ├── allure
  │   │   └── .gitkeep
  │   ├── img
  │   │   ├── .gitkeep
  │   │   ├── favicon.ico
  │   │   ├── how-it-works.png
  │   │   └── logo.jpg
  │   ├── index.md
  │   ├── moldb
  │   │   └── .gitkeep
  │   ├── objetos
  │   │   └── .gitkeep
  │   ├── swagger
  │   │   └── .gitkeep
  │   ├── unitest
  │   │   └── .gitkeep
  │   └── versions.json
  └── mkdocs.yml
  

• git remote remove origin

• git remote add origin <remote-repo-url>
• git pull <remote-repo-url> main
• git commit --amend
• git push -u origin main

Projetos MOTS¶

É um repositório de controle de versão que contém vários projetos, aplicativos ou componentes relacionados em um único repositório. Para aplicativos MOTS (Many Off-The-Shelf), que são aplicativos prontos para uso, há vários exemplos de produtos que adotam essa abordagem.

Temos tido muitas integrações de produtos internos ou outros ERPs, o que nos leva a pensar ONDE deixar o objeto, logo, podemos sempre deixar no PROJETO do MOTS, para tal há a necessidade em se trabalhar com submodules do git.

A utilização de submódulos, no git, faz-se necessária quando está delegando uma parte do projeto/produto a outro produto e deseja integrar o trabalho deles em um momento ou lançamento específico.

• Publique a alteração do submódulo antes de publicar a alteração no superprojeto que faz referência.
• Lembre-se de confirmar todas as suas alterações antes de executar,git submodule update.

Projetos Internos¶

Para sistemas internos, desenvolvidos internamente são cruciais ter um processo bem definido para garantir a eficiência, qualidade e segurança do desenvolvimento e implantação de software.

Keycloack¶

Uma solução de Identity and Access Management (IAM) de código aberto que oferece uma série de benefícios e justificações para sua utilização em projetos de software.

• IAM (Identity and Access Management):
  • Refere a um conjunto de políticas, processos e tecnologias utilizadas para gerenciar e controlar identidades de usuários, bem como suas permissões de acesso a sistemas, aplicativos e recursos.
• IDM (Identity Management):
  • Subcategoria do IAM e se concentra especificamente na gestão de identidades de usuários em sistemas de TI. Envolve o gerenciamento de informações sobre usuários, incluindo seus atributos, credenciais de autenticação, permissões e outros dados relacionados.

Arquétipos Maven¶

São templates de projetos que possibilitam iniciar o desenvolvimento de novos projetos de forma padronizada. É uma poderosa ferramenta de gerenciamento de construção para projetos para ajudar a executar uma estrutura de ciclo de vida de construção. A base do Maven é o conceito de POM (Project Object Model) em que todas as configurações podem ser feitas com a ajuda de um arquivo `pom.xml`.

Efetue a instalação do maven, você NÃO precisa abrir chamado para efetuar a instalação do maven. A instalação do Apache Maven é um processo simples de extrair o arquivo e adicionar o bin diretório com o mvn comando ao arquivo PATH.

Maven Wrapper¶

O Maven Wrapper garante que nosso projeto tenha tudo o que é necessário para executar a construção do Maven, instalando e gerenciando automaticamente uma versão específica do Maven. Por exemplo, se enviarmos um projeto Maven para o GitHub que desenvolvemos usando o Maven versão 3.9.6 e outra pessoa tentar construí-lo localmente usando uma versão mais antiga como 3.7, a compilação poderá falhar. O Maven Wrapper baixa e instala automaticamente a versão correta do Maven, se necessário, garantindo que o projeto use a versão correta do Maven, independentemente da instalação local do Maven.

Gerar arquivos Maven Wrapper¶

• Certifique-se de que nosso sistema instalou o Maven. Podemos verificar isso executando: mvn --version
• Navegue até o diretório raiz do projeto Maven: cd repositorio\PRODUTO
• Execute o seguinte comando para gerar arquivos Maven Wrapper. mvn wrapper:wrapper
• Agora, em vez de usar mvn para construir o projeto, podemos usar ./mvnw (no Linux ou macOS) ou mvnw.cmd(no Windows) para construir o projeto.
• O comando gerará os arquivos mvnw, mvnw.cmd e .mvn/wrapper/maven-wrapper.jar e .mvn/wrapper/maven-wrapper.properties no diretório do projeto.

Repositório local Maven¶

É o local onde o Maven armazena todos os arquivos jars do projeto, bibliotecas ou dependências. Por padrão, o nome da pasta é '.m2'

Repositório Central Maven¶

O repositório central do Maven é o local padrão 'http://artifacty.com/' para o Maven baixar todas as bibliotecas de dependência do projeto. Para qualquer biblioteca necessária no projeto, o Maven primeiro procura na pasta .m2 do Repositório Local; se não encontrar a biblioteca necessária, procura no Repositório Central e baixa a biblioteca no repositório local.

As etapas detalhadas são: Tenha uma instalação do JDK em seu sistema. Defina a JAVA_HOME variável de ambiente apontando para a instalação do JDK ou tenha o java executável no seu arquivo PATH.

• Extraia o arquivo de distribuição em qualquer diretório.
• Instale o arquétipo: 60opt-archtype-plsql, através do comando mvn clean install.

$ mvn -B archetype:generate -DarchetypeGroupId=br.com.60pportunities.archetypes -DarchetypeArtifactId=60opt-archetype-plsql -DarchetypeVersion=1.0-SNAPSHOT -DgroupId=br.com.60pportunities -DartifactId=exemploplsql
$ mvn wrapper:wrapper

Ciclo de Vida¶

O ciclo de vida é uma sequência predefinida de fases que guiam o build de um projeto por meio da execução de objetivos.

Instalação do Liquibase¶

Liquibase pode ser usado como uma ferramenta de linha de comando executada em macOS, Windows, Unix e Linux. Use a CLI do Liquibase para migrar seu banco de dados da linha de comando sem precisar integrar o Liquibase ao seu aplicativo ou instalar uma ferramenta de construção.

• Baixe e execute o instalador apropriado.
• Certifique-se de adicionar Liquibase ao seu PATH.

Camada de Persistência¶

Estratégia CI/CD (Integração Contínua/Entrega Contínua) para a camada de persistência utilizando Liquibase, será da seguinte forma.

Vertical Slice Architecture¶

A Vertical Slice Architecture nasceu da dor de trabalhar com Arquiteturas em Camadas. A Vertical Slice Architecture, por outro lado, organiza o código em torno de recursos ou casos de uso. Cada fatia representa uma funcionalidade especifica do projeto. E dentro de cada fatia cabe ao desenvolvedor definir qual caminho seguir para efetuar o comportamento dessa funcionalidade, ou seja, não é necessário encaixar cada pedaço do sistema dentro de uma estrutura rígida de camadas na hora de desenvolver. Portanto cada pedaço é desenvolvido de forma isolada seguindo seu próprio estilo de implementação.

Um recurso é um caso de uso de um problema que você está tentando resolver. Com a Vertical Slice Architecture,você organiza seu código em um recurso em vez de camadas. Isso significa que você pegará todas as questões técnicas relacionadas a um recurso e organizará esse código em conjunto. Concentre-se na organização pelos recursos e capacidades do seu sistema.

Ao fazer isso, você está lidando com o acoplamento de uma maneira diferente, porque as fatias são, em sua maior parte, independentes.

Em fatias verticais, cada fatia pode ter seu próprio método de acesso a dados em um armazenamento de dados. Uma fatia poderia usar micro-ORMs, enquanto outra poderia usar um ORM completo e outra poderia usar uma API externa. Você pode acabar com a duplicação de código e está tudo bem. Este é o preço a pagar pela autocontenção e pelo acoplamento frouxo com fatias verticais.

Monitoramento de Aplicação/Experiência do Usuário¶

É fundamental para monitorar e otimizar o desempenho de aplicações em produção. Monitoramento de contêineres, orquestradores, bancos de dados, cache e sistemas de armazenamento para garantir que estejam funcionando corretamente para garantir que os aplicativos estejam sendo executados corretamente e escalados conforme necessário.

Pipeline 60OPT¶

Build Artifacts x Pipeline Artifacts x Azure Artifacts¶

Os artefatos são criados para quase todos os processos de desenvolvimento de software , incluindo codificação, configuração, compilação, testes automatizados, arquivamento, empacotamento, documentação, requisitos mínimos viáveis de produto e etc.

Também posso restringir o artefato, como sendo qualquer tipo de arquivo que sua construção produz, ou que você pode querer reutilizar em outra construção, outro trabalho de sua construção ou um pipeline de implantação ou lançamento.

No Azure DevOps, os artefatos podem ser subdivididos em três categorias principais: Build Artifacts x Pipeline Artifacts x Azure Artifacts.

Build Artifacts¶

Os artefatos de construção são publicados por meio da tarefa Publish Build Artifacts e podem ser baixados com a tarefa Download Build Artifact. Os artefatos de construção podem ser consumidos de outros trabalhos no mesmo pipeline e de outros pipelines. Build Pipelines pode ser usado se você quiser consumir seu artefato de um Release Pipeline acionado pela conclusão da construção. Isso pode incluir arquivos executáveis, arquivos .dll, modelos de dados, bibliotecas ou arquivos de banco de dados. aqui estão alguns exemplos:

• Casos de teste, suítes de teste, relatórios de teste, Microsserviços, Código compilado.

Pipeline Artifacts¶

Estas são a versão mais recente , por assim dizer, do Build Artifacts e, como tal, podem ser usadas apenas nos pipelines YAML. Um dos principais benefícios dos artefatos de pipeline é que eles podem reduzir drasticamente o tempo necessário para fazer upload e download dos artefatos devido à forma como os arquivos são carregados e armazenados.

Para publicar os artefatos de pipelines, você pode usar a tarefa Publish Pipeline Artifact baixá-los usando a tarefa Download Pipeline Artifact.

Build vs Pipeline Artifacts¶

Os artefatos Build e Pipeline são muito genéricos, você pode salvar o que quiser neles, e o que o Azure DevOps faz é apenas empacotar os arquivos em um arquivo zip e salvá-lo em algum lugar.

Azure Artifacts¶

É mais um serviço de software específico do que uma categoria de artefato, mas vale a pena mencioná-lo aqui devido ao seu lugar no cenário do Azure DevOps. Azure Artifacts é um serviço pago para repositórios de artefatos superiores a 2 GB.

É um repositório onde ele suporta vários tipos de pacotes, como NuGet, npm, Python, Maven e etc. você pode basicamente vê-lo como uma alternativa ao Artifactory, Nexus e pacotes GitHub.

• Preço

Outra grande diferença é quanto ao preço. Quer você use Build Artifacts ou Pipeline Artifacts, você não terá que pagar um único centavo por eles, não importa quantos arquivos você armazene ou quão grandes eles sejam. Os Artefatos do Azure, por outro lado, são cobrados por tamanho.

• Build Artifacts somente se estiver usando Build Pipelines Clássicos.
• Pipelines Artifacts se você estiver em YAML Pipelines e não precisar compartilhar o resultado do seu CI com outras equipes.
• Artefatos do Azure se precisar compartilhar pacotes dentro da mesma equipe, entre organizações ou até mesmo publicamente.

Repositório de Artefatos¶

Mantém todos os artefatos seguros e com controle de versão. As ferramentas de construção ajudam a gerenciar dependências e outros artefatos compilados. Essas ferramentas fornecem uma fonte única de pacotes, gráficos Helm, imagens de contêiner e outros artefatos para integração perfeita com ferramentas de CI/CD e avanço no ciclo de vida de desenvolvimento de software.

Observabilidade¶

Refere-se a ferramentas de software e práticas para agregar, correlacionar e analisar um fluxo contínuo de dados de desempenho de uma aplicação distribuída, juntamente com o hardware e a rede em que ela opera permitindo monitorar, depurar e solucionar problemas na aplicação ou comportamento do mesmo.

• Monitoramento

Capacitando a melhor Análise de Negócios com Inteligencia Artificial¶

Imagine que quase tudo o que você faz é auxiliado por um agente/assistente de IA? Uma ferramenta de IA treinada para ser um Business Analysis ou treinada especificamente para ser um Business Analysis da sua organização?

Estamos vendo inúmeros prompts que escrevem histórias de usuários e critérios de aceitação, tomarem e analisarem notas de reuniões e muito mais!

Agora, e se tudo isso estivesse em um "agente" e você não precisasse "solicitar" isso.

Isso já está acontecendo e evoluirá rapidamente nas próximas semanas/meses. Algumas maneiras pelas quais isso está acontecendo:

• GPTs personalizados (públicos ou privados);
• Ferramentas do fornecedor (requisitos, modelos, análises e muito mais baseados em IA);
• Ferramentas de automação SDLC;
• E, mais por vir, tenho certeza.x`

E, BAs que são bem treinados nas habilidades, técnicas e habilidades de pensamento crítico corretas de BA usarão essas ferramentas e terão um desempenho dramaticamente melhor do que aqueles sem habilidades de BA em técnicas de BA, mentalidade e outras habilidades críticas de BA.

✅ Define o problema a ser resolvido e para quem estamos resolvendo antes de qualquer trabalho técnico ser definido. BAs ocupados definem os detalhes técnicos das soluções solicitadas, muitas vezes causando retrabalho.

✅ Obtém 100x o trabalho feito no valor entregue sobre o trabalho real que está sendo feito. Eles se concentram no valor em vez de fazer o trabalho de "requisitos", documentos concluídos e detalhes definidos. Dica... a maioria dos documentos e detalhes na verdade não precisa ser feita e não agrega valor. Nosso trabalho como BA é descobrir isso. BAs ocupados fazem tudo o que todos pedem deles, e é muito, mas agrega pouco valor.

✅ Use o tempo dos stakeholders de forma tão eficiente que eles estejam implorando por mais tempo dos BAs! Eles demonstram seu valor com a forma como criam conversas com os stakeholders, mostrando que há muito mais para falar, sem contar isso aos stakeholders. Um BA ocupado sempre sente que precisa de mais tempo dos stakeholders e normalmente não está realmente usando seu tempo de forma eficaz, na maioria das vezes está duplicando conversas que os stakeholders já tiveram com outros.

✅ Cria e reutiliza modelos visuais e outros artefatos para inspirar análises em si mesmos e nos outros. Essa análise é onde as lacunas nos requisitos são realmente encontradas. Um BA ocupado cria novos para cada projeto e os trata como entregas versus ativos usados ​​continuamente.

Gamificação¶

O objetivo é aumentar o engajamento, a motivação, bem como, a participação dos usuários. Este conceito envolve a utilização de pontuações, níveis, recompensas e desafios, para transformar atividades comuns em experiências mais interativas e divertidas.

• Kahoot!: Plataforma permite criar quizzes gamificados que engajam pessoas em tempo real. Util para perguntas e respostas, tornando o aprendizado mais atraente, pois incentiva a participação ativa. Ajuda no desenvolvimento de habilidades, como trabalho em equipe e resolução de problemas, e com isso melhorando o engajamento dos funcionários, aumentando a produtividade e promovendo uma cultura organizacional positiva.
• KARMA: É uma ferramenta que gamifica o gerenciamento de tarefas, recompensando os usuários com pontos à medida que completam tarefas.

Sugestão de Calendário¶

Calendários dos Projetos(Sugestão)¶