DEV Community: Rafael

Lazy/Eager - Carregamento de Entidades utilizando JPA com SpringBoot

Rafael — Wed, 11 May 2022 20:44:19 +0000

Um dos pontos mais importante na construção de um software é a performance, portanto entender as queries e otimizá-las ao máximo que puder pode resultar num belo ganho de desempenho.

Partindo dessa premissa e por mais que utilizamos frameworks como SpringBoot que otimizam todo esse processo entender o funcionamento do lazy e do eager da JPA(Java Persistence API) é fundamental para o desempenho de um APP, pois o uso de maneira errada pode resultar em grandes perdas de performance e forçar a aplicação a realizar diversas queries desnecessárias no banco de dados (podendo ocasionar assim o tão famoso problema das N+1 consultas).

Lazy - Carregamento Preguiçoso

Vamos começar nossos estudos entendendo o lazy que é o carregamento default da JPA quando você não especifica nada. O lazy não faz o carregamento de determinados objetos até que você precise deles(daí vem a tradução de preguiçoso) ele ocorre quando temos entidades associadas para muitos isto é quando temos algum relacionamento OneToMany na nossa entidade.

Eager - Carregamento Ansioso/Guloso

Oposto ao Lazy o eager ja traz do banco os objetos mesmo que você não vá utiliza-los, ele ocorre quando temos entidade associadas para um, isto é quando temos algum relacionamento ManyToOne na nossa entidade.

Exemplificando

Vamos supor que no meu domínio de negócio eu tenho duas classes que se relacionam da seguinte maneira:

Reparem que no exemplo acima eu tenho um relacionamento um-para-muitos, já que um team pode conter muitos palyers e muitos players podem pertencer a um time.

Pelo padrão da JPA quando eu busco um Player a JPA já traz do banco o team ao qual ele pertence(Eager), já quando eu busco o team a JPA não traz do banco os jogadores pertencentes ao time (Lazy)

Vendo o Funcionamento na Pratica o Funcionamento do Eager

Para vermos como isso ocorre na pratica construí uma API com base no modelo apresentado acima(o link do projeto no GitHub estará ao final do artigo).

Na minha API tenho as seguinte classes mapeadas:

No pacote Resource da minha API eu criei um controller com a seguinte configuração:

Reparem que nesse controller eu chamo um service que irá buscar os dados do player pelo id e do resultado jogo num DTO que eu chamei PlayerDTO, portanto quando faço pelo browser/Postman/Insonia a seguinte chamada (localhost:8080/player/1) a API retorna os seguintes dados do player:

Bem se habilitarmos o sql lá no nosso application.properties, para vermos as queries que a API faz lá no console veremos o seguinte detalhe:

Vejam que mesmo não precisando dos dados do team a JPA faz um join (desnecessário nesse caso já que eu só quero os dados do player) na minha tabela team conforme destacado em amarelo, já que como vimos acima por padrão toda vez que a entidade tem uma associação para um o carregamento e eager.

Agora você deve se está se perguntando então como eu faço para customizar essa busca, isto é quero evitar esse join desnecessário?

Bem uma forma e você definir um fetch na mão(muita cautela ao fazer isso pois você pode estar piorando a performance em outros endpoints dependendo do contexto do negócio) da seguinte maneira:

Ao rodarmos a consulta novamente veremos na console a seguinte query:

Reparem que desta vez ele não fez join la na minha tabela team e tudo funcionou de boa.

Vendo o Funcionamento na Prática do Lazy

Continuando no estudo da nossa API vamos vê agora o funcionamento do Lazy, para isto no meu pacote resource criei o seguinte controller

Reparem que nesse controller eu chamo um service que irá buscar os dados do team pelo id e do resultado jogo num DTO que eu chamei TeamDTO, portanto quando faço pelo browser/Postman/Insonia a seguinte chamada (localhost:8080/team/1) a API retorna os seguintes dados do team:

Agora se dermos uma olhada novamente no console veremos as seguintes queries:

Reparem que quando executamos essa chamada o JPA faz duas queries na primeira ele busca os dados do player e na segunda de team.
Bem agora você deve esta se fazendo uma outra pergunta, Ué mas como ele fez essa mágica?

Isso só ocorreu pois lá no TeamService eu faço a seguinte chamada conforme vemos abaixo:

result.get().getPlayers()

O getPlayers() que usei disparou outra consulta no banco para buscar os dados do player. Portanto conforme vimos acima por padrão toda vez que a entidade tem uma associação para muitos o carregamento é Lazy(preguiçoso) a JPA não traz o objeto até que você precise dele.

Considerações Finais

O objetivo deste artigo foi justamente apresentar aos leitores os conceitos do Fetch/Eager tão utilizados na JPA. O bom entendimento desses conceitos pode acarretar em ganhos de performance na sua aplicação desde que você adote a melhor prática baseado no seu modelo de negócio.

Links/Referencias Bibliográficas

Repositório do Git da demo: https://github.com/rmarinheiro/demolazyeager

https://www.baeldung.com/hibernate-lazy-eager-loading

Desenvolvimento em Camadas utilizando DTO

Rafael — Wed, 23 Feb 2022 00:14:18 +0000

Durante a construção de um sistema em java é comum dividirmos nossa aplicação num modelo que chamamos de camadas, o grande “barato” desse modelo é a possibilidade de separarmos componentes de acordo com as suas responsabilidades.

Muitos desenvolvedores principalmente a galera que tá começando agora acha bobagem isso(é só mais um processo burocrático que a galera do Java inventou), mas se formos pensar em grandes projetos de software onde há uma grande quantidade de desenvolvedores atuando em torno do mesmo projeto, não arquitetar o sistema em camadas pode implicar em códigos ilegíveis e confusos, dificultando e muito a vida de novos devs que venham no futuro a dar manutenção no sistema em questão.

Exemplificando

Vamos supor que tenhamos a seguinte arquitetura de camadas no nosso projeto:

No Item 1 temos a nossa aplicação web se comunicando com o nosso controller por meio de chamadas Http passando objetos JSON;
No Item 2 temos o nosso controller(que é componente responsável pelas interações com a camada web), recebendo as solicitações vindas da web e chamando o service passando um objeto do tipo DTO (ja vamos falar dele mais abaixo).
No Item 3 o nosso service(que é o componente responsável em executar as partes lógicas e regras de negócio da nossa aplicação) pega esse objeto DTO transforma para o padrão entidade mais popularmente conhecido como ORM(Mapeamento Objeto Relacional) e passa esse objeto que ele acabou de converter para o repository.
No Item 4 o repository( que é a camada responsável pelo acesso a dados) vai até o Banco de Dados e executa a consulta.

Reparem que após a execução da consulta no banco o repository retorna o objeto ORM para a camada service, esse por sua vez transforma novamente para o padrão DTO e devolve esse DTO para a camada controller e esse por sua vez devolve novo DTO obtido para camada web.

Mas Afinal o que é esse tal DTO que tanto foi falado acima?

O DTO(Data Transfer Object) como o próprio nome já diz é um padrão de projeto onde tem como intuito transferir dados de um local para o outro da aplicação sem nenhum tipo de regra de negócio embutida no meio,possibilitando assim que façamos uma ordenação dos dados antes de exibirmos na nossa aplicação e uma diminuição no tráfego de rede,já que não há mais necessidade de retornar uma entidade com uma paulada de atributos.

Vamos supor que tenhamos na nossa aplicação a seguinte classe:

Repare que a minha classe User eu possuo algumas informações sigilosas como password e id(que é a forma como a informação é armazenada no banco de dados), por questões de segurança não gostaríamos de exibir essas informações através de um serviço rest. Se optarmos por utilizar diretamente essa classe User no retorno dos nossos métodos dentro da nossa classe controller iremos expor essas informações e não é isso que queremos,para resolver esse problema podemos criar uma classe chamada UsuarioDTO e ao invés de retornar nos nossos métodos todos os atributos da entidade vamos retornar o DTO com os atributos que queremos isto é “omitimos” as informações que queremos exibir, conforme podemos vê no exemplo abaixo:

Repare que no código acima e estou definindo que o meu UsuarioDTO só vai ter os atributos nome e email os demais eu estou "omitindo".

Um outro ponto a se observar no código acima é que utilizamos um método construtor que tem a finalidade de converter uma entidade no nosso caso User em um objeto do tipo DTO que no nosso caso se chamará UsuarioDTO.

Portanto toda vez que a nossa camada service estiver devolvendo dados para o controller precisaremos chamar este construtor conforme podemos ver no exemplo abaixo:

Caso queiramos fazer o inverso isto é converter de DTO para entidade poderíamos criar um método privado dentro da classe UserService onde faríamos essa conversão conforme podemos ver no exemplo abaixo:

Lembrando que esta é apenas uma das formas que a galera usa para fazer conversão de DTOs para entidades e vice e versa, existem algumas ferramentas com modelmapper que facilita a vida nesse processo de conversão.

Considerações Finais

A ideia deste artigo foi mostrar aos leitores a idéia central acerca do padrão de projeto DTO, mostrando sua real utilidade na forma como podemos proteger dados sensíveis, além de mostrar a você leitor o real ganho de qualidade e de organização de código quando adotamos uma arquitetura baseada em camadas.

Documente sua API SpringBoot com Swagger

Rafael — Thu, 02 Sep 2021 01:27:23 +0000

Documentação é um ponto essencial e chave para qualquer projeto de softwares eu costumo dizer que a documentação é o coração de qualquer projeto, afinal uma aplicação que está mal documentada ou com nenhum tipo de documentação pode dificultar o entendimento por parte da equipe e de usuários sobre o comportamento da mesma.
Portanto neste artigo iremos mostrar uma poderosa ferramenta que tem como intuito ajudar desenvolvedores nessa tarefa de criar boas documentações de suas APIs de forma rápida e automatizada.

O que é SWAGGER?

Swagger é um framework opensource composto por diversas ferramentas, que auxilia o desenvolvedor na descrição, no consumo e na visualização de uma API REST,no entanto para realizar tais tarefas o Swagger se utiliza de uma especificação chamada OPENAPI que define um padrão padronizado de uma requisição JSON.
Como já dissemos anteriormete o swagger é composto por diversas ferramentas mas as principais são:

Swagger Editor - sua função principal é ajudar o desenvolvedor a definir uma estrutura de uma API no inicio de um projeto(https://editor.swagger.io/)
Swagger Codegen - sua função principal é criar todo o “esqueleto” da API a partir de uma descrição em YAML.
Swagger UI - sua função principal é criar uma documentação elegante,por meio de uma interface gráfica, onde usuários podem descrever suas APIs e realizar testes nas mesmas sem que haja qualquer tipo de dano aplicação em ambiente de produção.

Neste artigo vamos mostrar como integrar uma aplicação java utilizando o Swagger UI.

Adicionando a Lib SpringFox numa API com Spring Boot

Com a aplicação criada e com os endpoints funcionando,adicione no pom.xml essas duas dependências:

<dependency>
    <groupId>io.springfox</groupId>
    <artifactId>springfox-swagger2</artifactId>
    <version>2.9.2</version>
</dependency>

<dependency>
    <groupId>io.springfox</groupId>
    <artifactId>springfox-swagger-ui</artifactId>
    <version>2.9.2</version>
</dependency>

Com as dependências recém colocadas na aplicação chegou a hora de habilitar o swagger, para isto no pacote principal da aplicação dentro da classe Application(classe esta que dá o start na aplicação e inicializa todos os beans) ou se preferir você pode criar uma classe de configuração SwaggerConfig conforme podemos vê abaixo:

Neste método estamos definindo que nosso bean que chamamos de Docket terá acesso a todos os endpoints da aplicação, além disso criamos um método privado que retorna um objeto do tipo ApiInfo
que tem como objetivo criar informações customizadas acerca dos nossos endpoints.Com isso através de reflection a lib já consegue obter os endpoints que estão disponíveis na aplicação.
Para acessar o Swagger UI é necessário digitar(http://localhost:8080/swagger-ui.html) o resultado será semelhante ao da figura abaixo:

Personalizando Mensagens Globais:

Caso você precise personalizar todos os códigos de retorno que um endpoint retorne você precisará utilizar dentro do nosso bean Docket o método globalMessage recebendo como parâmetro um método http e uma lista de ResponseMessage conforme podemos ve abaixo(no meu caso eu fui definindo atributos final do tipo ResponseMessage e na chamada do globlaResponseMessage fui colocando esses atributos dentro de um array)

Utilizando Autenticação no Swagger

Caso sua aplicação utilize algum tipo de autenticação é necessário configurarmos no SpringFox, para isto utilizamos dois métodos o securityContext e SecurityScheme. No primeiro método defino o tipo de autenticação( se é ApiKey,BasichAuth,OAuth) e o segundo defino particularidades da autenticação.

No exemplo abaixo definimos uma autenticação do tipo ApiKey dentro do nosso bean Docket e definimos que o endpoint pedido deverá ter uma autenticação:

Após isso, rode novamente e ao acessar novamente a tela do Swagger-UI você verá no canto direito o botão Authorize conforme podemos vê na imagem abaixo:

Ao clicar nele ele pedirá que você informe seu token

Após informar seu token já será possível realizar consultas nos endpoints que exijam autenticação

Fundamentos de Teste Automatizados

Rafael — Sun, 04 Jul 2021 00:56:17 +0000

Por mais que se planeje a construção de um software,fazendo o uso de tecnologias de ponta do mercado, adotando as melhores práticas no desenvolvimento de uma aplicação, erros são passíveis de ocorrer, o que acaba gerando grandes dores de cabeça para usuários projetistas e prejuízos astronômicos para empresas principalmente se for uma aplicação com alta criticidade.
Quem já passou por isso sabe o quão desagradável é ficar na mão quando um programa fecha de forma inesperada devido a um bug no sistema, este fato poderia ter sido evitado caso a equipe em questão estivesse como hábito a utilização das ferramentas de teste apropriadas para a detecção do bug.
Portanto um dos benefícios quando temos o hábito de testar um software é detectar de forma rápida se determinada mudança acaba violando determinada regra e qual impacto que essa mudança pode trazer para quem está utilizando o software, simulando casos reais e avaliando se todas as funcionalidades entregues estão funcionando de forma correta e segura, em outras palavras é no teste que podemos avaliar se o programa está funcionando de forma esperada. Justamente por todos esses argumentos já citados que equipes e empresas gastam tempo e recursos na adoção de ferramentas e metodologias de teste.
Atualmente existem diversos tipos de testes para detectarmos os mais variados cenários(daria até para fazer um livro) mas o enfoque do artigo será nos testes automatizados.

O que é um teste automatizado?

No decorrer do desenvolvimento e na manutenção de um sistema a complexidade tende a aumentar, projetista e desenvolvedores passam a ter dificuldades em avaliar se os recursos estão funcionais ou não pois o software que antes contemplava poucos cenários agora passa a atender um número muito maior de casos deixando sua complexidade "N" vezes maior..
Para auxiliar os times de alta performance na avaliação de softwares é que utilizamos os testes automatizados que nada mais é que um software escrito por alguém que tem intuito de avaliar o seu sistema.

3 tipos de testes automatizados

Os testes funcionais podem ser feitos de diversas maneiras, mas as 3 abordagens que o mercado mais utiliza que tem como intuito detectar bugs no menor tempo possível sem comprometer a qualidade do sistema são:

1.Teste Unitário
É o teste feito pelo desenvolvedor tem como intuito validar o comportamento funcional do código, em outras palavras estamos testando os métodos de uma classe, com base numa determinada entrada qual resposta que esperamos que aconteça.
Nesse tipo de teste não podemos acessar outros componentes(isto é não podemos criar objetos de outras classes), ou recursos externos(como bd,rede, web services e etc).
Caso haja necessidade de instanciar objetos de outras classes ou simularmos o retorno de algum webservice para executarmos um teste unitário por exemplo utilizamos de um artifício que é mocar um objeto ou serviço(isto é criar um objeto fake ) para podermos simular o resultado esperado. Utilizamos uma ferramenta muito popular usada para realizarmos o mock é o mockito.
Nos testes unitários também utilizamos uma ferramenta muito famosa chamada Junit.

2.Integração
Também conhecido como teste de web service/API é o teste voltado em verificar a comunicação entre componentes/módulos e recursos externos de uma aplicação. O objetivo deste teste é verificar se a interação entre os componentes e APIs está ocorrendo de forma correta.
Geralmente neste tipo de teste utilizamos ferramentas já conhecida por desenvolvedores como SoapUI e PostMan.

3.Funcional
É o teste do ponto de vista do usuário final que tem como finalidade verificar se uma determinada funcionalidade tá sendo executada da forma esperadacomo foi planejada, em outras palavras estamos testando os nossos casos de uso.

Benefícios em Utilizar Teste Automatizados

Como já dito acima um dos benefícios em utilizar testes automatizados em um projeto é detectar de forma mais rápida se determinadas mudanças violam regras de negócio.
Além disso o uso testes automatizados é uma forma de documentar aplicação, já que quando estamos implementando os testes na nossa aplicação a lógica tende a ser a mais simples clara e objetiva possível,o comportamento dos métodos quais entrada/saídas e os resultados esperados.
Redução de custos de manutenção, pois num desenvolvimento de software a etapa de validação,homologação e até mesmo de manutenção é muito custosa, portanto se a sua aplicação estiver com uma boa cobertura de testes certamente você passará por essa etapa sem muitas dores no bolso.
Melhorias no design da solução, pois a cada feature nova a aplicação é testada, possibilitando mudanças na estrutura arquitetural de uma aplicação.

TDD - Test Driven Development

Antes de mais nada é importante esclarecermos que TDD é nada mais que um método de desenvolver testes isso significa dizer que o TDD é uma definição da maneira como a equipe irá trabalhar na elaboração dos testes, não é o foco do TDD avaliar se os testes estão sendo bem ou mal executados ou se o projeto tem ou não tem testes.Além disso não significa necessariamente que um software só por ter testes automatizados possa ser de cara já encaixado no padrão do TDD.

Principais Vantagens Na Utilização do TDD

Foco nos requisitos isto é no TDD você começa primeiro pelos testes antes de sair de cara implementando algo. Neste momento você não está preocupado como o método será implementado e sim qual o comportamento e esperado dele após inserirmos uma determinada informação.
Melhora o design da aplicação pois o código desenvolvido passa a ser testado repetidas vezes, evitando que tenhamos que escrever códigos demasiadamente complexos.
Dá mais segurança ao desenvolvedor na hora de implementar novas
funcionalidades, tendo assim mesmo chance de quebrar a aplicação devido alguma feature nova.

Processo Básico

Bem já que falamos que o TDD é um metodologia para o desenvolvimento de testes abaixo vamos listar alguns itens básicos levados em consideração no TDD.

Como já dito acima o TDD prega a cultura de escrever primeiro os testes antes de sair desenvolvendo um método, nesta etapa a preocupação é descrever o comportamento do método baseado numa entrada(é natural que nesta etapa o seu teste ainda esteja falhando pois o componente ainda não foi implementado).
Agora sim nessa etapa você deverá implementar o código, os casos de uso e os componentes necessários para que o teste passe.
Essa etapa é opcional e avalia a necessidade de refatoração do código mediante a necessidade.

Boas Praticas e Padrão Quando Estamos Implementando Testes Automatizados

Neste tópico vou procurar mostrar algumas das melhores praticas e padrões quando estamos desenvolvendo testes automatizados(eu sei que é um tema polêmico e não existe uma regra universal e cada equipe faz da forma que deseja), mais abaixo procuro demonstrar o que na visão de vários especialistas é importante:

Nomenclatura de Teste (AÇÃO should EFEITO when CENÁRIO)

Dado uma ação qual será o efeito(should efeito) dela mediante aquele cenário(when cenário) exemplos:

Ação : Método Delete
Efeito: Dado um determinado ID deverá excluir um determinado registro do BD.
Cenário: Quando o ID existir

Ação : Método Delete
Efeito: Lançar uma exceção quando a aplicação não encontrar um ID Cenário: Quando o ID não existir

Padrão AAA

Arrange : Primeiro instancie os objetos necessários(de new nos objetos que você irá utilizar)
Act: execute as ações necessárias isto é faça o que tem de ser feito no método isto é caso seja necessário inserir/atualizar um dado no Banco de Dados por exemplo
Assert: declare o que deveria acontecer (resultado esperado).

Princípio da Inversão de Controle(SOLID)

Uma classe A jamais poderá depender da instância de uma classe B(se isso estiver sendo feito esse teste não pode ser chamado de teste unitário). Caso você precise acessar instâncias de outras classes precisaremos criar mocks(objetos fakes como já dito acima).
Isso acaba ajudando na testabilidade do método garantindo assim o isolamento da unidade a ser testada.

Independência

Um teste não pode depender de outro teste e a ordem de como o teste será executado pouco importa, portanto é uma boa pratica que os testes sejam independentes um não pode ficar dependendo de dados do outro.

Cenário Único

Cada teste deve ter um cenário especifico, e sua lógica deve ser a mais simples possível sem o uso de loops ou operadores condicionais.
Se você reparou no exemplo acima foi criado um cenário onde um ID existia e um outro cenário onde não existia o ID.

Previsibilidade

O resultado de um teste deve ser sempre o mesmo para os mesmos dados,evite que o seu teste faça depender de coisas que variam como: timeStamp atual(new Date,instant.now) e valores aleatórios (como random).

Manual de Sobrevivencia:Git/GitHub

Rafael — Fri, 25 Jun 2021 22:10:26 +0000

100 em cada 100 desenvolvedores preferem utilizar o Git/GitHub para controle e hospedagem dos arquivos fontes(se você não leu o artigo anterior onde apresento e dou uma breve explicada sobre controle e versionamento de código corre lá [https://dev.to/rs_marinheiro/controle-de-versao-versionamento-de-codigo-1hg].
Criado por Linus Trovalds em 2005(isso mesmo o mesmo cara que criou o Linux) o git acabou se tornando a ferramenta de versionamento open-source mais utilizada por empresas e desenvolvedores ao redor do mundo, além de funcionar bem em várias IDEs ,Sistemas Operacionais, permite integração com softwares de terceiros como Jira por exemplo.
Este artigo tem como objetivo de apresentar ao leitor esta poderosa ferramenta,de versionamento de código,e mostrar aos leitores comandos essenciais do dia a dia para quem deseja sair do ponto inicial.

Como já mencionamos no artigo anterior o Git trabalha de forma distribuída e por trabalhar de forma distribuída o git se divide em 4 áreas diferentes conforme podemos ver na figura abaixo:

Working Directory(Diretório Trabalho) : como o próprio nome já diz é o diretório onde você utiliza para trabalho, sem correr o risco de estragar nada, é como se você estivesse usando um localHost da vida para editar seus arquivos.

Stagging Area(Area de Estagiamento): é o cara que faz o meio de campo entre seu diretório local e o repositório local,é nessa área onde ficam os arquivos que estão aptos a serem salvos no repositório local.De forma análoga é como se estivéssemos usando esta área para colocar numa caixa aquilo que desejamos subir para produção.

LocalRepo(RepositorioLocal): local onde os seus fontes ficam salvos, todas as alterações ficam em uma pasta compacta dentro do diretório .git.De forma análoga é como se estivéssemos fechando a caixa com os itens que colocamos no passo anterior.

RemoteRepo(Repositorio Remoto):local responsável por centralizar em um só lugar todos os repositórios de todos os desenvolvedores envolvidos do projeto. Essa centralização é feita através do uso de servidores remotos como mais popular temos o GitHub.

Agora que você conheceu um pouco a forma de funcionamento do git vamos por a mão na massa.

Instalação

Caso você ainda não tenha o git instalado a seguir disponibilizo link que te ajudara a instala-lo na sua máquina Linux/Windows/Mac (sua instalação é bem simples nada que faça você perder o sono)
[https://git-scm.com/]

Após instalação abra o terminal de sua preferência(caso você esteja utilizando o Windows você pode utilizar o Git Bash Here vá em qualquer pasta com o botão direito abra o Git Bash Here) rode o seguinte comando git --version com na imagem abaixo:

Se o resultado for igual o da imagem parabéns o git foi instalado corretamente.

Configurações Iniciais

Após a instalação do git é necessário que você configure seu usuário e coloque seu endereço de email afinal de contas as pessoas precisam saber quem é você e quem fez determinada alteração no código para isso no seu terminal digite o seguintes comandos:

git config --global user.name “Seu Nome”
git config --global user.email “Email que você vai utilizar”

Pronto após essa configuração o próximo passo será a criação de um repositório local para que possamos realizar nossos commits e em seguida possamos hospedar no github.
Para isso na pasta onde encontra-se o seu projeto rode o seguinte pela linha de comando o comando git init.:

Aqui vale uma ressalva ao rodar esse comando o git cria uma pasta oculta .git dentro do diretório conforme imagem abaixo(caso você não esteja visualizando este arquivo na pasta onde foi rodado o comando é necessário habilitar a visualização de arquivos ocultos no Painel de Controle do Windows ou do sistema operacional que estiver usando)

Comandos Básicos

Após rodar o comando git init na pasta onde se encontra o seu projeto, você agora pode querer visualizar quais arquivos que estão no seu projeto e que você deseja coloca-los na área de stage(como já mencionamos acima) para isto pelo terminal na pasta onde você criou seu repositório local rode o seguinte comando git status:

Verifique que após rodarmos esse comando foi possível visualizar que o arquivo que eu tinha acabado de adicionar no repositório(novo_documento.txt) ficou com a cor vermelha isto significa que este arquivo já está apto para ser colocado na área de stage, para isto vamos rodar o seguinte comando git add . (como o próprio git nos sugere na imagem acima) e como podemos visualizar na imagem abaixo:

Após rodarmos esse comando e dermos novamente um git status você verá o seguinte resultado:

O arquivo que eu criei que antes estava na cor vermelha agora aparece na cor verde isto significa que este arquivo agora está pronto para ser commitado.

Para commitarmos basta dar o seguinte o comando git commit -m “Comentário Qualquer” conforme vemos na imagem:

OBSIMP: Sempre procure ser o mais sucinto possível na hora de adicionar um comentário lembre-se que você está trabalhando em equipe e as pessoas precisam entender o que você fez ninguém trabalha por adivinhação.**

Pronto você acaba de fechar o seu pacote de alterações/mudanças e agora você já pode mandar pro gitHub, mas caso você precise vê um log de tudo que foi feito no projeto você tem a opção de rodar o comando git log conforme vemos na imagem a seguir.

Aqui vale uma breve ressalva no destaque em amarelo mostra um código hash criado pelo git após realizarmos o commit. Esse código é criado pelo git toda vez que commitamos algo é através desse código hash que o git identifica cada commit realizado no seu projeto.

Criação do Repositório Remoto

Nesse passo é necessário que você já esteja com a conta no GitHub criada, após a criação da conta clique na foto do seu perfil e selecione a opção Your Profile como podemos vê na figura.

E em seguida selecione a opção new conforme imagem abaixo:

Na tela seguinte crie um nome para o seu repositório conforme destaque da imagem

Aqui vale outra ressalva caso você queira deixar seu projeto privado e só marcar a opção private

Configurando o SSH

Antes de subir o projeto para o servidor GitHub é necessário configurar as chaves SSH, mas afinal o que é isso?

A chave ssh é um protocolo de segurança exigido pelo GitHub que permite que somente a maquina na qual você configurou tenha acesso aos repositórios remotos, isso quer dizer que se você tentar acessar algum repositório remoto de uma outra maquina diferente da que você configurou, o GitHub não permitirá

OBSIMP: Aqui vale um ponto de atenção desde o dia 13 de Agosto de 2021 o GitHub não permite mais que usuários entre com usuário e senha via linha de comando, daí a necessidade de configurarmos a chave SSH.

Pelo terminal do GitBash digite o seguinte comando:

ssh-keygen -t ed25519 -C "your_email@example.com"

-Logo após que você digitar esse comando de enter até o fim no processo de geração das chaves. Após esse passo vá até a pasta onde as chaves foram gerada(no meu caso ele gerou na pasta .ssh dentro do diretório C:/Usuarios/rafael do windows), e copie o conteúdo contido no arquivo de extensão .pub.

Adicionando a Chave no GitHub

Acesse sua conta no GitHub e no canto superior clique na setinha ao lado da foto e escolha a opção settings;
No canto esquerdo selecione a opção(SSH and GPG Keys);
E depois clique no botão New SSH Key
Na tela Seguinte coloque um nome qualquer para sua chave e no campo key cole a chave publica que você obteve no topico anterior e clique no botão Add SSH Key.
Logo na sequencia você verá a chave recém configurada na sua conta GitHub, porém se faz necessário reiniciar a maquina (principalmente se você estiver utilizando Windows para que o Windows consiga reconhecer suas credencias)

Enviando seu Arquivo Para o GitHub

Bem agora chegou a hora de mandar os nosso pacotinho pro servidor remoto para isto você verá que após a criação do repositório remoto o git apresenta a seguinte tela que nada mais que é uma espécie de colinha para mandar seus fontes pro servidor remoto:

Para isto basta roda no seu terminal os dois últimos comandos(fazendo uma breve explicação desses comandos podemos perceber):
O comando git remote associa o repositório remoto ao repositório local da sua maquina;
O comando git push de fato pega todos os commits que foram realizados e manda lá pra main(este é o nome que o git coloca para determina que este cara é o repositório principal do seu projeto).

Após rodarmos esse comando e em seguida irmos lá no gitHub e clicarmos no nome do nosso repositório você já verá que as alterações já estão contidas dentro do servidor do gitHub conforme imagem abaixo:

Bem pessoal essa foi uma pequena introdução de como trabalhar com git/github além de apresentar alguns comandos básicos do dia a dia para que você comece a sair da inércia.
Nos próximos artigos iremos nos aprofundar um pouco mais no fluxo do git.

Controle de Versão (Versionamento de Código)

Rafael — Sat, 16 Jan 2021 21:14:06 +0000

Este artigo tem como intuito apresentar um dos conceitos que muitos iniciantes na área de desenvolvimento de software se deparam quando começam a desenvolver softwares de forma colaborativa e paralela o versionamento de código também conhecido como controle de versão.
Não precisamos dizer que o código fonte é um “bem precioso” que precisa ser guardado e bem gerenciado para que catástrofes não venham a acontecer e jogar por água abaixo anos de trabalho e conhecimento adquirido ao longo de desenvolvimento de um sistema. Além disso o versionamento de código acaba ajudando os times a rastrear alterações feitas ao longo do desenvolvimento de um produto, facilitando assim na resolução de bugs sem prejudicar as demais versões estáveis que estão rodando em produção.
Legal mas você deve estar se perguntando agora como funciona esse controle de versão?
Antes de mais nada você precisa entender que o sistema de controle de versão trabalham de duas formas:

• O centralizado modelo este utilizado pelo SVN(também conhecido como Subversion) ele trabalha com o modelo de arquitetura chamada cliente-servidor(conforme podemos ver na figura abaixo) ou seja você tem um servidor central responsável pela versão estável do sistema que está em produção(trunk) e diversas ramificações (branchs) onde os desenvolvedores utilizam para desenvolver novas features do sistema.
Após essas features passarem por todo o processo de validação/testes é necessário que a equipe de desenvolvimento realize o que chamamos de merge isto é juntar as alterações dos fontes feitas pelo desenvolvedor na branch que ele utilizou para desenvolver em conjunto com a última versão estável que está em produção.Como você já percebeu uma das desvantagens deste modelo de versionamento é a escalabilidade quando temos muitos desenvolvedores atuando no mesmo repositório, e também não há a possibilidade de trabalhar offline, já que é necessário sempre estar conectado ao servidor. A figura abaixo ilustra um pouco essa metodologia de trabalho

• Já o modelo distribuído muito utilizado pelo popular GIT trabalha de uma forma um pouco diferente, cada desenvolvedor tem seu próprio “servidor” portanto as operações de check-in e check-out são realizadas na própria máquina do desenvolvedor e diferentemente do modelo centralizado, neste modelo as maquinas do desenvolvedores comunicam-se entre si. Por ser um modelo muito complexo onde diversos desenvolvedores do mundo todo podem atuar num mesmo projeto, recomenda-se a utilização de um servidor remoto que tem como intuito hospedar o projeto afim de evitar perdas de código ao longo do desenvolvimento de um sistema, conforme podemos observar na figura abaixo:

Dentre os servidores remotos mais famosos que trabalham de forma distribuída temos: o GitHub(o mais popular e muito utilizado pela galera de OpenSource acabou se tornando uma espécie de rede social dos desenvolvedores), e o BitBucket(utilizado em projetos onde você deseja ter uma privacidade maior).Como já falamos por se uma metodologia onde o “servidor está na máquina do próprio desenvolvedor” o sistema distribuído acaba sendo mais rápido em comparação ao centralizado porém exige do time em questão um conhecimento mais apurado das ferramentas e comandos que rodam em linha de comando.

Bem depois dessa breve apresentação no próximo artigo iremos falar mais sobre o GIT, como funciona, principais comandos para criação e manipulação de repositórios.