Ir para o conteúdo principal

Novo colaborador? Comece por aqui!

Olá!

Seja muito bem-vindo(a) ao nosso time! 👋

Preparamos este espaço com muito carinho para ser seu apoio nos primeiros dias conosco. Aqui você encontrará os materiais e todas as informações necessárias para iniciar sua jornada.

Estamos super animados para ter você aqui! 😊

1. Conhecendo nossos produtos:

  • Alterdata Backup: Ferramenta padrão para backup e restauração dos sistemas desktop da Alterdata, com a capacidade de enviar cópias para a nuvem.
  • Alterdata Installer: Aplicativo para a instalação inicial dos sistemas desktop da Alterdata, configurado com base nos produtos que o cliente adquiriu.
  • Bunker: Solução de backup desenvolvida para clientes que utilizam serviços em nuvem, cloud ou "servidor na nuvem".
  • Karoo Enterprise (em breve LiveChat): Plataforma de chat principal pela qual os clientes se comunicam com os analistas da Alterdata.
  • Prosoft Backup: Ferramenta padrão para backup e restauração dos sistemas desktop da Prosoft, também com a opção de enviar cópias para a nuvem.
  • Updatecenter: Conjunto de APIs responsável por gerenciar o licenciamento e a atualização de todos os produtos Alterdata para os clientes.
  • Updater (ainda): Camada intermediária que conecta os sistemas desktop ao Updatecenter, realizando consultas e entregando respostas aos sistemas.

2. Onde hospedamos as APIS, Serviços e Bancos dos nossos produtos?

3. PAT's de teste:

São computadores do Cirrus na matriz, ligados pela infra e acessados via acesso remoto "mstsc".

  • PAT-3033: Ip na rede: 172.16.21.65
  • PAT-2472: Ip na rede:172.16.21.76

4. Repositório dos sistemas na Rede

Antes de acessar é preciso mapear a rede, conforme esse manual da infra: Mapeamento de diretórios na Rede: Linux e Windows

O repositório pode ser acessado de duas formas:

5. Onde estão as aplicações dos sistemas?

Todos os nossos sistemas possuem duas versões principais: Produção (ambiente real e em uso) e Staging (ambiente de testes, uma cópia fiel da produção).

Abaixo, você encontrará os detalhes de acesso às interfaces de Produção e informações sobre as aplicações:

6. Bancos de dados de teste-  🚧 à completar:

7. Monitores dos sistemas (Alterdata Backup e Bunker):

Atualmente temos dois monitores que nos ajudam a verificar os envios dos backups de clientes para a nuvem

8. Documentações de APIS:

Utilizamos o Swagger como uma ferramenta essencial para documentar nossas APIs e realizar testes.

Com ele, você pode:

  • Visualizar todos os endpoints existentes em nossos serviços.
  • Entender a funcionalidade de cada um.
  • Consultar os parâmetros necessários para as requisições.

Além disso, o Swagger está integrado ao nosso banco de dados de testes, o que significa que todas as requisições realizadas diretamente pela interface do Swagger serão executadas neste ambiente de teste.

Você pode acessar o Swagger do Updatecenter aqui: http://swagger-ui-updatecenter-qa.alterdatasoftware.com.br/

 E o Swagger do Karoochat por aqui: https://review-gateway-karoo-chat.alterdatasoftware.com.br/ajuda

9. Como funciona a Sprint?

Este tutorial detalha como as tarefas são criadas, priorizadas e desenvolvidas no seu time, seguindo uma metodologia ágil utilizando o Jira da Atrlassian: https://jira.alterdata.com.br/

1. Criação e Organização das Tarefas

As tarefas são criadas inicialmente pelo time, sejam Devs, Qas ou o próprio time de suporte, e essas tarefas vão indo para o Backlog

Todo o backlog é organizado de acordo com os produtos/projetos específicos do time.

2. Planejamento (Planning) e Votação das Tarefas

O processo de planejamento ocorre em sessões de planning.

  1. Seleção das Tarefas: Durante o planning, o Tech Lead seleciona as tarefas do backlog que serão consideradas.
  2. Votação: Após a seleção, o time realiza uma votação para estimar o esforço de cada tarefa. Esta votação segue a sequência de Fibonacci (1, 2, 3, 5, 8, 13...).
  3. Discussão e Voto Final: Depois da votação individual, o time discute cada tarefa para chegar a um consenso e definir o voto final. Esse processo se repete para todas as tarefas selecionadas.
3. Início e Execução da Sprint

Uma vez que as tarefas são votadas, a sprint se inicia.

  • Duração da Sprint: Uma sprint dura 2 semanas corridas, ou, aproximadamente 10 dias úteis.
  • Papel dos Desenvolvedores (Devs): Os desenvolvedores iniciam o trabalho nas tarefas que foram definidas e votadas.
  • Papel dos Analistas de Qualidade (QAs): Os Qas iniciam a sprint com tarefas que são designadas para o time de qa, tais como liberações, análise de situações reportadas, etc. Quando os devs finalizam as tarefas de programação, automaticamente as tarefas de teste, vinculada as issues, ficarão disponíveis na fila de tarefas pendentes de teste.

Durante o período de desenvolvimento pelos devs, os QAs não ficam ociosos. Eles aproveitam esse tempo para realizar outras atividades importantes, como:

  • Execução de testes e levantamento de requisitos em tarefas avulsas (que não fazem parte do sprint atual, mas estão no backlog).
  • Criação de documentação referente aos produtos ou processos.
  • Resolução de problemas específicos que surgem no dia a dia.

💽 Sistemas úteis para baixar em sua máquina de trabalho:

¹ Diretório com algumas VDIs (máquinas virtuais)  completas de sistemas operacionais, como Windows 10 x64, Windows 11 etc para ser utilizadas em conjunto com o VirtualBox:
Pasta com Cópias das máquinas virtuais no Drive


🎒 Materiais de apoio:

Materiais para QA

 

Antes de mergulhar de cabeça nessa aventura, te convidamos a fazer um curso especial: "Primeiros Passos do Técnico de Qualidade", oferecido pela nossa UCA. Ele será um excelente ponto de partida!

Clique aqui para dar seus primeiros passos como QA

Materiais para DEV

 

 

Divisão Alterdata: Padrões de desenvolvimento

Fluxo de trabalho no GIT + JIRA

  • Criar o(s) merge(s) no momento de criação da branch (Vamos tentar automatizar)

  • Colocar o link do(s) merge(s) no comentário da tarefa pai

Padrão de microservice NestJS
Geral: Tipagens

      • Não utilizar any nos tipos de objeto

      • Definir interfaces ou tipos para entrada e saída dos métodos e funções

      • Os tipos/interfaces devem seguir o padrão de nome exemplo.interface.ts

      • O arquivo de uma interface deve ser a estrutura: /interfaces/exemplo.interface.ts

      • Sempre priorizar o uso de constantes

      • As constantes devem ser inseridas em um arquivo próprio constantes

      • Exemplo: common/constates.ts

      • Sempre priorizar o uso de enuns

      • Os enuns devem estar em um arquivo próprio

      • O arquivo de enum deve ser a estrutura: /enuns/exemplo.enum.ts

      • A pasta enuns pode ficar dentro de uma pasta common geral ou dentro do escopo do módulo. Essa definição depende do contexto.

      • As entradas e saídas dos endpoints devem ser sempre definidas com os DTOs

      • Criar um DTO por arquivo

      • Seguir o padrão do nome da classe ExemploDTO

      • Seguir o padrão do nome do arquivo ./dtos/example.dto.ts

      • Todas as propriedades devem possuir os decorators do swagger possuindo uma breve descrição sobre o campo e um exemplo de input.
        Exemplo:

DTOs de entrada:

      • Todas as propriedades devem ser definidas como readonly

      • Todas as propriedades devem possuir os devidos decorators do NestJS para que o recurso de validação dos dados seja devidamente utilizado.
        Exemplo:

Geral: Tratamento de exceções

      • As classes de exceptions devem ser criadas sempre em um arquivo separado

      • Um arquivo de exception pode conter mais de uma classe de exception, desde que essas façam parte de um mesmo escopo.

      • Exemplo: Arquivo de exception que contenha mais de uma classe de exceção do Bimer

      • O nome da classe de exception deve seguir o padrão ExemploException

      • Os arquivos de exception devem seguir o padrão de nome exemplo.exception.ts

      • O arquivo de exception deve ser a estrutura: ./exceptions/exemplo.exception.ts

Controller:

      • Evitar ao máximo ter regra de negócio na camada de controller

      • Todos os métodos de endpoints devem estar definidos com os DTOs de entrada e saída

      • Fazer o uso do @res no endpoint apenas para os casos em que for necessário, como por exemplo, Redirect ou manipulação de arquivos

      • Evitar o uso de json como valor de querystring da url

      • Fazer o devido uso dos métodos GET / POST / PUT / DELETE:

        • GET: Apenas para consultas

        • POST: Apenas para cadastrar novas informações

        • PUT: Apenas para alterar informações

        • DELETE: Apenas para remover informações

Serviços:

      • Aqui nós temos as regras de negócio e SOMENTE a regra de negócio

      • Não deve conter queries

      • Cada serviço deve estar em um arquivo único

      • Os arquivos de serviços devem seguir o padrão de nome exemplo.service.ts

      • Os arquivos de serviços devem seguir o padrão de estrutura: ./services/exemplo.service.ts

      • No arquivo de serviço não deve conter:

        • Definição de interfaces ou DTOs

        • Definição de classes de exceptions

        • Definição de constantes ou enuns

Entidades:
Postgres

        • Utilizar o typeORM

        • Consultas ao banco devem ficar sempre na classe da entidade

        • Criação de queries personalizadas devem ficar em métodos estáticos dentro da classe de entidade

Mongoose

        • Criar e manter os schemas, exemplo: example.schema.ts

        • Criar e manter os repositórios

        • O repositório deve sempre herdar a classe base.repo.ts

        • Nos repositórios não deve conter nenhuma regra de negócio

        • Cada repositório deve conter apenas as consultas ao banco de dados do seu escopo

        • Nomenclatura padrão: example.repo.ts

Nats

      • Criar as interfaces sempre dentro da pasta lib

      • Cada interface deve estar em um arquivo único

      • Os arquivos de interface devem seguir o padrão de nome exemplo.interface.ts

      • Os arquivos de interface devem seguir o padrão de estrutura: /lib/interfaces/nome-do-modulo/exemplo.interface.ts

Performance

      • Evitar if encadeados sem necessidade

      • Cuidados nas interações repetidas

Testes Unitários (à definir)
Padrão de frontend (à definir)

  • Componentes

Boas práticas de programação

  • Utilizar o recurso de index.ts quando houver mais de uma classe no mesmo escopo, exempo: entidades, dtos, exceptions

Observações gerais do projeto Karoo

  • Sempre que houver alteração na pasta Lib, é necessário executar o build do monorepo para que as alterações fiquem disponíveis em todos os pontos

  • Backend: Deve ser escrito SEMPRE em português

  • Frondend: Deve ser escrito SEMPRE em inglês

  • Sempre utilizar o serialize para traduzir a comunicação entre backend e frontend




Temos bastante materiais no Drive do Cirrus que podem ser acessados através desse link: Materiais do Blue Team