DEV Community: Luiz Bernardo

Comparativo entre os Protocolos de Comunicação PROFINET e PROFIBUS PA

Luiz Bernardo — Tue, 01 Aug 2023 01:24:23 +0000

Os protocolos de comunicação são essenciais para garantir a troca eficiente e segura de dados entre dispositivos em sistemas de automação e controle industrial. Dois dos protocolos mais amplamente utilizados na indústria são o PROFINET e o PROFIBUS PA. Ambos foram desenvolvidos pela PROFIBUS & PROFINET International (PI) e são amplamente adotados em diferentes aplicações industriais. Neste artigo técnico, faremos um comparativo detalhado entre esses dois protocolos, abordando suas principais características, funcionamento, características técnicas, meios físicos de comunicação, vantagens, desvantagens e tipos de aplicações.

PROFINET

Principais Características:

PROFINET é um protocolo de comunicação Ethernet industrial em tempo real.
É uma tecnologia avançada que combina o padrão Ethernet com as vantagens do PROFIBUS.
Suporta uma ampla variedade de dispositivos, desde controladores lógicos programáveis (PLCs) até sensores e atuadores.

Princípio de Funcionamento:

PROFINET utiliza uma arquitetura baseada em Ethernet para fornecer comunicação em tempo real e não em tempo real.
Utiliza o conceito de "slots" e "subslots" para endereçar dispositivos, permitindo comunicação direta entre eles.

Características Técnicas:

Taxas de comunicação variáveis de 100 Mbps a 1 Gbps, proporcionando alta velocidade de transferência de dados.
Suporte para comunicação assíncrona (TCP/IP) e síncrona (RT) em uma única infraestrutura.

Meio Físico de Comunicação:

PROFINET utiliza cabos Ethernet padrão (Cat 5e ou Cat 6) para a comunicação entre dispositivos.
Possibilita a utilização de redes Ethernet existentes, tornando a instalação mais conveniente e econômica.

Vantagens:

Alta velocidade e largura de banda, adequadas para aplicações de controle em tempo real.
Flexibilidade e escalabilidade, permitindo a fácil adição de dispositivos à rede.
Suporte a comunicação em tempo real e não em tempo real em uma única rede.

Desvantagens:

Requer maior conhecimento técnico para a instalação e configuração em comparação com protocolos mais simples.
Custo inicial pode ser maior devido à infraestrutura de rede * Ethernet necessária.

Tipos de Aplicações:

Automação de processos industriais em linhas de produção.
Controle de máquinas e equipamentos em indústrias manufatureiras.
Sistemas de transporte automatizados em logística.

PROFIBUS PA

Principais Características:

PROFIBUS PA é uma variação do protocolo PROFIBUS DP (Decentralized Periphery) projetado especificamente para automação de processos.

Princípio de Funcionamento:

PROFIBUS PA utiliza uma arquitetura de barramento, onde os dispositivos são conectados em série a um único cabo.

Características Técnicas:

Taxa de comunicação de 31.25 kbps, adequada para aplicações de automação de processos.
Suporte para comunicação em tempo real e não em tempo real.

Meio Físico de Comunicação:

PROFIBUS PA utiliza cabos de par trançado (intrinsecamente seguro) ou segmentos de tronco Exd/Exi (à prova de explosão) para a comunicação.

Vantagens:

Adequado para ambientes industriais agressivos e classificados como áreas explosivas (Ex).
Baixo custo de instalação e manutenção devido à simplicidade da topologia em barramento.

Desvantagens:

Velocidade limitada em comparação com protocolos Ethernet, não sendo ideal para aplicações de controle de alta velocidade.
Escalabilidade limitada em grandes redes.

Tipos de Aplicações:

Automação de processos em indústrias químicas, petroquímicas e de óleo e gás.
Controle de processos de produção em indústrias de alimentos e bebidas.

Conclusão

Tanto o PROFINET quanto o PROFIBUS PA são protocolos confiáveis e amplamente utilizados na indústria. A escolha entre eles dependerá das necessidades específicas de cada aplicação. O PROFINET é mais adequado para aplicações de alta velocidade e controle em tempo real, enquanto o PROFIBUS PA é mais adequado para ambientes com classificação Ex e aplicações de automação de processos. Em última análise, ambas as tecnologias fornecem soluções eficientes para uma variedade de aplicações industriais, contribuindo para maior eficiência e segurança em processos industriais.

Azure Board com quadro Kanban

Luiz Bernardo — Fri, 02 Jun 2023 12:39:13 +0000

Coisas do dia a dia que aprendi usando o Azure Board com quadro Kanban

Os quadros Kanban proporcionam uma representação visual do fluxo de trabalho, mostrando os itens do backlog, histórias de usuário ou bugs em diferentes estágios de conclusão.

O Kanban prioriza duas práticas principais: visualizar o fluxo de trabalho e limitar a quantidade de trabalho em andamento (WIP).

Para utilizar um quadro Kanban, é necessário se conectar a um projeto e ser adicionado a uma equipe ou projeto. Também é preciso ter as permissões adequadas para adicionar e modificar itens de trabalho.

Você pode acessar o seu quadro Kanban pelo portal da web, selecionando a equipe correta no menu de seleção de equipes.

Ao utilizar um quadro Kanban, é importante mapear os estágios do fluxo de trabalho da sua equipe e configurar o quadro de acordo. É possível personalizar as colunas para corresponder aos estágios do seu fluxo de trabalho.

É fundamental estabelecer limites de WIP para cada estágio do fluxo de trabalho, a fim de garantir uma carga de trabalho gerenciável e identificar possíveis gargalos.
É possível adicionar itens de trabalho ao quadro Kanban inserindo um título e pressionando Enter. Os itens de trabalho podem ser atualizados ao movê-los para diferentes estágios ou modificando os campos diretamente no quadro.

Existem opções de filtragem disponíveis para focar em subconjuntos específicos de trabalho com base em palavras-chave, valores de campo ou tags.

Monitorar as métricas é uma parte essencial do Kanban. O Diagrama de Fluxo Cumulativo (CFD) fornece insights sobre o progresso do trabalho e pode ajudar a otimizar os processos.
As atualizações em tempo real podem ser ativadas para que o quadro Kanban seja atualizado automaticamente quando ocorrerem alterações.

Widgets de análise e o Serviço de Análise podem ser utilizados para uma análise mais aprofundada e visualização das métricas.

Evite Commits Problemáticos e Mantenha seu Projeto Limpo

Luiz Bernardo — Tue, 23 May 2023 12:47:36 +0000

Um commit é um registro das alterações feitas em um projeto por meio de um sistema de controle de versão, como o Git. É importante evitar fazer commits com código quebrado ou com bugs, pois isso pode ter consequências negativas. Esses commits comprometem a qualidade do código, dificultam a manutenção futura, tornam mais complicado o rastreamento de problemas, afetam a integração contínua e prejudicam a reputação do desenvolvedor. Para manter um código de qualidade, facilitar a colaboração e preservar a confiança da equipe, é fundamental evitar commits problemáticos.

Uma maneira eficaz de garantir commits limpos é utilizar o SonarLint. O SonarLint é uma ferramenta de análise de código que auxilia os desenvolvedores a identificar e corrigir problemas de qualidade em tempo real. Ele se integra perfeitamente a ambientes de desenvolvimento populares, destacando problemas no código-fonte e fornecendo sugestões de correção. Essa ferramenta é uma versão local do SonarQube, projetada especificamente para atender às necessidades dos desenvolvedores individuais.

Para saber mais: What is SonarLint?

Como configurar o SonarLint

Primeiramente você vai precisar do Sonar, seja SonarQube (Self-managed) ou SonarCloud (As a service).

A instalação do SonarLint é similar em quase todas IDE:

Instale a extensão pelo marketing place da própria IDE
Configure a conexão com token.

Para criar um token de usuário no SonarQube ou SonarCloud, siga estes passos:

Faça login no SonarQube ou SonarCloud com uma conta de administrador.
No painel, clique no ícone do seu avatar no canto superior direito e selecione "My Account" (Minha Conta).
Na página "My Account", clique na guia "Security" (Segurança) no menu lateral esquerdo.
Role a página até encontrar a seção "Tokens" e clique em "Generate Tokens" (Gerar Tokens).
Na página de criação de token, forneça um nome descritivo para o token, que possa identificar seu propósito ou uso.
Selecione as permissões que deseja conceder ao token. Você pode optar por Global User Token ou User token (com menos permissão).
Após selecionar as permissões, clique em "Generate" (Gerar).
O SonarQube irá gerar o token e exibi-lo na tela. Anote o token em um local seguro, pois ele será mostrado apenas uma vez. Tenha cuidado para não perdê-lo, pois você precisará do token para autenticação em API ou integração com outras ferramentas.
Após anotar o token, clique em "Done" (Concluído).

Ao incorporar o SonarLint em seu fluxo de trabalho, você poderá identificar problemas de qualidade do código enquanto estiver escrevendo, permitindo que os resolva antes de fazer um commit. Isso ajuda a melhorar a qualidade geral do código, facilita a manutenção futura e evita problemas que possam surgir durante o desenvolvimento. Além disso, commits mais limpos e livres de bugs tornam mais fácil o rastreamento de problemas, promovem uma integração contínua suave e contribuem para a reputação positiva do desenvolvedor e da equipe.

Como utilizar o Kibana para visualizar e analisar dados no Elastic

Luiz Bernardo — Thu, 11 May 2023 19:56:11 +0000

Antes de começar a usar o Kibana, você precisa instalar o Elastic Stack. O Elastic Stack é composto pelo Elasticsearch, Logstash e Kibana. Você pode baixá-lo em elastic.co/downloads. Siga as instruções de instalação para o seu sistema operacional.

Iniciar o Elasticsearch e o Kibana

Após a instalação, inicie o Elasticsearch e o Kibana. Você pode fazer isso usando o terminal ou a interface gráfica do Elastic. Para iniciá-los pelo terminal, use os seguintes comandos:

cd /caminho/do/elasticsearch
bin/elasticsearch

cd /caminho/do/kibana
bin/kibana

Indexar seus dados

Antes de poder visualizar seus dados no Kibana, você precisa indexá-los no Elasticsearch. Existem várias maneiras de fazer isso, como por exemplo, usando o Logstash, que é um pipeline de processamento de dados. O Logstash pode ajudar a coletar, transformar e enviar dados para o Elasticsearch.

Conectar o Kibana ao Elasticsearch

Depois de indexar seus dados, é hora de conectar o Kibana ao Elasticsearch. Abra o Kibana no seu navegador (geralmente em http://localhost:5601) e siga os seguintes passos:

Na página inicial do Kibana, clique em "Connect to your Elasticsearch index".
Escolha uma das opções de conexão disponíveis (por exemplo, local ou remota).
Selecione o índice que você deseja visualizar no Kibana.

Criar um Dashboard

Agora que você conectou o Kibana ao Elasticsearch, é hora de começar a visualizar seus dados. Uma maneira fácil de fazer isso é criando um dashboard, que é uma coleção de painéis que mostram visualizações diferentes dos seus dados. Siga os seguintes passos para criar um dashboard:

Clique em "Dashboard" no menu à esquerda do Kibana.
Clique em "Create Dashboard".
Escolha o tipo de visualização que deseja adicionar ao seu painel (por exemplo, gráfico de barras ou tabela).
Escolha o índice que deseja usar para a visualização.
Selecione a coluna que você deseja visualizar.
Selecione a métrica que deseja usar para a visualização.
Clique em "Create Visualization" para adicionar a visualização ao seu painel.
Repita os passos 3 a 7 para adicionar outras visualizações ao seu painel.
Clique em "Save" para salvar seu painel.

Agora você tem um dashboard personalizado para visualizar seus dados no Kibana. Mas isso é apenas o começo. Existem muitos recursos e funcionalidades no Kibana que você pode explorar para melhorar a análise de seus dados. Aqui estão algumas dicas adicionais para ajudá-lo a aproveitar ao máximo o Kibana:

Use filtros para restringir a visualização de seus dados a um subconjunto específico. Você pode usar filtros para selecionar dados com base em um intervalo de tempo, valores de campo específicos ou outros critérios.
Experimente com diferentes tipos de visualizações, como gráficos de dispersão, mapas geográficos e gráficos de pizza. Cada tipo de visualização pode ajudá-lo a entender diferentes aspectos de seus dados.
Personalize suas visualizações usando opções de formatação e estilos. Você pode mudar a cor, tamanho e tipo de letra dos seus gráficos, por exemplo, para torná-los mais atraentes e legíveis.
Explore os recursos de colaboração do Kibana. Por exemplo, você pode compartilhar seus painéis e visualizações com colegas de trabalho ou criar permissões de acesso personalizadas para diferentes usuários.
Aprenda a usar consultas KQL (Kibana Query Language) para pesquisar seus dados com mais precisão. Você pode usar consultas KQL para filtrar e agrupar seus dados com base em critérios complexos.
Considere a possibilidade de usar plug-ins do Kibana para adicionar funcionalidades adicionais ao seu sistema. Existem muitos plug-ins disponíveis no mercado, desde ferramentas de monitoramento até visualizações personalizadas.

Com essas dicas em mente, você estará bem equipado para começar a explorar os recursos do Kibana e aprofundar seus insights sobre seus dados. Boa sorte!

Configurando um Cluster Elasticsearch em Contêineres Docker

Luiz Bernardo — Sun, 30 Apr 2023 03:03:08 +0000

O Elasticsearch é uma poderosa ferramenta de análise e busca de dados distribuída que permite que os usuários armazenem, pesquisem e analisem grandes volumes de dados em tempo real. É construído em cima do Apache Lucene, uma biblioteca de busca de texto de código aberto e amplamente utilizada.

No entanto, configurar um cluster Elasticsearch pode ser uma tarefa complexa e desafiadora, envolvendo vários processos, como a instalação do software, a configuração de rede e o gerenciamento de nós. Além disso, é importante garantir que o cluster esteja disponível, escalável e seguro.

É aí que entra o Docker, uma plataforma de virtualização de software que permite que os usuários empacotem e executem aplicativos em contêineres leves e portáteis. Com o Docker, os usuários podem criar contêineres que possuem todas as dependências necessárias para executar seus aplicativos, incluindo o Elasticsearch.

O elastic-docker, um projeto de código aberto desenvolvido por Guilherme Silveira, é uma excelente opção para quem deseja configurar um cluster Elasticsearch facilmente. O projeto fornece um conjunto de scripts e configurações para executar um cluster Elasticsearch em contêineres Docker. Além disso, o elastic-docker é compatível com as versões mais recentes do Elasticsearch e do Docker.

Com o elastic-docker, é possível configurar um cluster Elasticsearch com várias instâncias em contêineres Docker separados de forma fácil e rápida. O projeto oferece scripts para configurar o número de nós, o tamanho do cluster e outras opções avançadas. Além disso, o elastic-docker pode ser personalizado de acordo com as necessidades específicas do usuário. É possível modificar as configurações padrão do Elasticsearch e utilizar plugins personalizados para adicionar recursos adicionais ao seu cluster.

Uma das principais vantagens do elastic-docker é que ele simplifica o processo de configuração de um cluster Elasticsearch, eliminando a necessidade de configurar a rede e gerenciar os nós manualmente. Com o elastic-docker, os usuários podem criar um cluster Elasticsearch escalável e disponível em questão de minutos.

Para começar com o elastic-docker, é necessário instalar o Docker em seu computador e, em seguida, baixar os scripts e configurações do projeto no GitHub e seguir as instruções de configuração fornecidas. Com sua personalização e facilidade de uso, o elastic-docker se torna a solução perfeita para aqueles que desejam configurar seu cluster Elasticsearch sem enfrentar os desafios comuns dessa tarefa.

Projeto elastic-docker no GitHub

Usando Terraform no Azure Pipelines

Luiz Bernardo — Wed, 26 Apr 2023 14:06:00 +0000

Já vimos o que é Azure Pipelines e agora vamos construir uma pipeline para executar um código Terraform.

Para saber mais o que é o Terraform: https://developer.hashicorp.com/terraform/tutorials/aws-get-started

Para executar um código terraform precisaremos do programa binário de Terraform e o AWS CLI, vamos ver como configurar cada um deles.

Primeira configuração e a trigger, nessa configuração informamos qual branch será utilizado para iniciar a pipeline de forma contínua e integrada.

trigger:
  branches:
    include:
    - master

Em seguida, escrevemos as estruturas básicas do Azure Pipelines de stages, jobs e steps.

stages:
- stage: DeployTerraform
  displayName: Deploy Terraform
  jobs:
  - job: DeployTerraform
    displayName: 'Deploy infrastructure with Terraform'
    steps:

Agora vamos criar nosso primeiro step de instalação do programa binário de Terraform no job que estamos executando.

Relembrando o job funciona como um container para a execução das etapas da nossa pipeline.

- bash: |
    echo "# Downloading Terraform v1.3.7"
    wget https://releases.hashicorp.com/terraform/1.3.7/terraform_1.3.7_linux_amd64.zip
    echo "# Unzipping files"
    unzip terraform_1.3.7_linux_amd64.zip

    echo "# Configuring terraform and checking version"
    export TERRAFORM_PATH=$(which terraform)
    ls -lha
    sudo mv terraform $TERRAFORM_PATH

    terraform -v

Por último, vamos instalar o AWS Cli utilizando a task AWSShellScript@1 e executar os comandos do Terraform para realizarmos o build e deploy do nosso Terraform.

    - task: AWSShellScript@1
      displayName: 'Deploy Service'
      inputs:
          awsCredentials: aws-teste-dev
          regionName: $(AWS_REGION)
          scriptType: 'inline'
          inlineScript: |
            terraform init
            terraform plan
            terraform apply -auto-approve
            terraform destroy -auto-approve

Beleza, mas a task AWSShellScript@1 exige a utilização de credenciais de acesso aos serviços AWS, para isso, precisamos criar uma IAM user credentials.

Para criar a IAM user credentials basta seguir o passo a passo da AWS no link https://docs.aws.amazon.com/cli/latest/userguide/cli-authentication-user.html

Agora precisamos configurar a credencial criada no Azure Pipelines, para isso vamos utilizar a configuração Service Connections.

O Service Connections do Azure Pipelines é um recurso que permite que você conecte seus pipelines a serviços externos, como Azure, GitHub, Bitbucket, Jenkins, Docker Hub, etc.

Essa conexão é estabelecida por meio de um endpoint seguro, que é uma configuração de conexão que inclui as credenciais necessárias para se comunicar com o serviço externo. O endpoint é criado e gerenciado pelo Azure Pipelines e pode ser usado em seus pipelines para se conectar ao serviço externo.

Ao criar um Service Connection, você pode configurá-lo com diferentes tipos de autenticação, dependendo do serviço externo que está sendo usado. Por exemplo, ao conectar-se ao Azure, você pode usar a autenticação baseada em certificado, enquanto que para o GitHub, você pode usar autenticação baseada em token.

Uma vez que o Service Connection é criado e configurado, ele pode ser usado em seus pipelines para conectar seus repositórios, contêineres, máquinas virtuais e outros serviços. Por exemplo, você pode usar um Service Connection para se conectar ao seu repositório GitHub e implementar seu aplicativo em um ambiente de hospedagem do Azure.

Além disso, o Azure Pipelines também permite que você compartilhe seus Service Connections com outros projetos e equipes na organização, o que simplifica o gerenciamento de credenciais e aumenta a segurança.

Agora vamos instalar o AWS Toolkit for Azure DevOps No Azure Devops

Acesse o link: https://marketplace.visualstudio.com/items?itemName=AmazonWebServices.aws-vsts-tools
Clique em "Get it free"
Selecione a organização que deseja instalar e clique no botão "Install"

Agora podemos utilizar as credenciais criadas no Service Connections através do AWS Toolkit for Azure DevOps.

Acesse o projeto no Azure Devops e clique em Project Settings
Em pipelines, clique em Service Connection
Clique em New service connection e selecione AWS, clique em Next
Insira as credenciais criadas em Access Key ID e Secret Access Key
Inclua o Service connection name, marque o checkbox Grant access permission to all pipelines e clique em Save

O Service connection name é muito importante pois ele será utilizado na task AWSShellScript@1 no input awsCredentials.

Por último, vamos criar um código Terraform simples. Utilizei o mesmo código utilizado no AWS get started da Hashicorp.

terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 4.16"
    }
  }

  required_version = ">= 1.2.0"
}

provider "aws" {
  region  = "us-west-2"
}

resource "aws_instance" "app_server" {
  ami           = "ami-830c94e3"
  instance_type = "t2.micro"

  tags = {
    Name = "ExampleAppServerInstance"
  }
}

Agora é só seguir o passo a passo de como executar uma pipeline, post com mais detalhes:

Pronto, você tem uma pipeline executando código Terraform.

Build no Azure Pipelines

Luiz Bernardo — Tue, 25 Apr 2023 12:34:29 +0000

Existem basicamente quatro níveis de linguagens de programação:

Linguagens declarativas: linguagens que descrevem a lógica de um programa, sem especificar os passos para alcançar um resultado específico. Elas se concentram mais no que deve ser feito do que em como deve ser feito.
Linguagens de alto nível: linguagens abstratas e de fácil entendimento para os programadores, que oferecem recursos poderosos para resolver problemas em diferentes áreas.
Linguagens de montagem: linguagem de baixo nível que utiliza códigos mnemônicos para representar as instruções do processador, facilitando a programação em baixo nível.
Linguagens de máquina: linguagem de baixo nível que utiliza códigos binários para interagir diretamente com o hardware do computador.

As linguagens mais altas precisam ser interpretadas e compiladas para uma linguagem mais próxima da linguagem da máquina, a esse processo damos o nome de build.

Build é o processo de compilar, vincular e empacotar código fonte em um produto de software executável ou em uma biblioteca. O objetivo do build é transformar o código fonte em um formato que possa ser executado pelo sistema operacional ou plataforma de destino.

Transformar as fontes em um sistema em execução pode muitas vezes ser um processo complicado envolvendo compilação, mover arquivos, carregar esquemas nas bases de dados, e assim por diante. No entanto, como a maioria das tarefas nesta parte do desenvolvimento de software, isso pode ser automatizado - e, como resultado, deve ser automatizado.

Para isso temos sistemas como o Maven, um compilador de códigos Java. O Maven constrói um projeto usando seu modelo de objeto de projeto (POM) e um conjunto de plugins. Depois de se familiarizar com um projeto Maven, você saberá como todos os projetos Maven são construídos. Isso economiza tempo ao navegar em muitos projetos.

O Maven possui uma arquitetura em camadas que consiste em quatro componentes principais:

Repositório: é um local onde os artefatos (bibliotecas, plugins, etc.) são armazenados e compartilhados entre projetos.

Plugin: é um conjunto de metadados que define um objetivo específico que pode ser executado pelo Maven, como compilar o código fonte ou gerar um relatório.
Core: é o coração do Maven, responsável por orquestrar a execução dos plugins e gerenciar as dependências do projeto.
CLI (Command Line Interface): é a interface de linha de comando que os desenvolvedores usam para interagir com o Maven.

Basicamente usamos o CLI do Maven para realizar um build.

Vamos pro build

Porém, uma boa forma é um build e fazermos com automação. Bora usar o Azure Pipelines pra isso.

Crie um hello world simples para demonstração e subi no repositório https://github.com/brbernardo/hello-world-java-maven

Agora vamos para o YML, já vimos como construir uma pipeline simples no post https://dev.to/bernardo/azure-pipelines-3k9, mas dessa vez, vamos usar uma task ja pronta. Vamos utilizar a task: Maven@4

A task: Maven@4 e mantida pela Microsoft e seu repositorio é o https://github.com/microsoft/azure-pipelines-tasks/tree/master/Tasks/MavenV4

Só precisamos incluir o bloco de código

steps:
- task: Maven@4
  inputs:
    mavenPomFile: 'pom.xml'
    mavenOptions: '-Xmx3072m'
    javaHomeOption: 'JDKVersion'
    jdkVersionOption: '1.8'
    jdkArchitectureOption: 'x64'
    goals: 'package'

E executar a pipeline que seu primeiro build será feito :)

Azure Pipelines

Luiz Bernardo — Wed, 19 Apr 2023 17:44:29 +0000

O Azure DevOps é um conjunto de ferramentas de colaboração e gerenciamento de projetos desenvolvido pela Microsoft para suportar a entrega de software de maneira ágil e eficiente. Ele inclui recursos para gerenciamento de código-fonte, planejamento de projetos, rastreamento de problemas, implantação automatizada, testes e integração contínua.

O Azure DevOps é composto por vários serviços, incluindo o Azure Repos para controle de versão de código-fonte, o Azure Boards para gerenciamento de projetos e planejamento ágil, o Azure Artifacts para gerenciamento de pacotes e artefatos de build, o Azure Test Plans para gerenciamento de testes e o Azure Pipelines para executar as pipelines dos projetost.

Bora falar de Azure Pipelines =D

O Azure Pipelines permite a criação de pipelines de integração contínua e entrega contínua (CI/CD), ajudando as equipes de desenvolvimento a automatizar todo o processo de criação e implantação de aplicativos, desde a compilação até a implantação em diferentes ambientes.

O Azure Pipelines pode interagir com outros serviços do Azure Devops, uma sugestão de interação seria essa:

No Azure Board você gerencia o seu projeto e cria a sua task. Você também pode associar o repositório do Azure Repos a sua task.
O Azure Repos é utilizado como servidor de repositório remoto de código ele pode ser criado com base no Git ou TFVC. Recomendo criar com base em Git.
O Azure Pipelines executa as pipelines que vamos ver aqui como funciona.
O Azure Test armazena os planos de execução e os testes executados pela pipeline.
O Azure Artifacts armazena os artefatos binários gerados pelos builds das aplicações do Azure Pipelines.

Composição de pipelines no Azure

Existem 3 agrupamentos lógicos na construção da pipeline no Azure Pipelines: pipelines, stages e steps.

Um "trigger" diz a um "Pipeline" para executar.
Um "pipeline" é composto por uma ou mais "stages".
Um "pipeline" pode ser implantado em um ou mais ambientes.
Uma "stages" é uma maneira de organizar "job" em um "pipeline" e cada "stages" pode ter um ou mais job.
Cada "job" é executado por um "Agent". Um "job" também pode não ter agente.
Cada "agent" executa um "Job" que contém uma ou mais steps.
Uma "step" pode ser uma tarefa ou script e é o menor bloco de construção de um "pipeline".
Uma "task" é um script pré-embalado que realiza uma ação, como invocar uma API REST ou publicar um artefato de construção.
Um artefato é uma coleção de arquivos ou pacotes publicados por uma execução.

Escrevendo a Pipeline

As pipelines são escritas com um arquivo de configuração YAML, ele seria um JSON melhorado, para saber mais: https://yaml.org/

Como vimos anteriormente, vamos precisar de 4 blocos de código: trigger, stages, jobs e steps. Cada um deles tem seus parâmetros e atributos, vejamos como fica em um código simples.

trigger:
  branches:
    include:
    - master
stages:
- stage: AzurePipelines
  displayName: 'Hello World for pipelines'
  jobs:
  - job: AzurePipelines
    displayName: 'Hello World for pipelines'
    steps:
      - script: echo "hello to my first pipeline"

Para saber mais sobre os parâmetros e atributos consulte a referencia de schema da Microsoft https://learn.microsoft.com/en-us/azure/devops/pipelines/yaml-schema/

Tudo certo você terá sua primeira execução de pipeline.

Log de execução

Achei interessante trazer o log de execução para vermos cada comando executado na pipeline a partir do nosso código simples.

##[section]Starting: Hello World for pipelines
##[section]Starting: Initialize job
Agent name: 'Azure Pipelines 2'
Agent machine name: 'fv-az179-88'
Current agent version: '2.220.0'
##[group]Operating System
Ubuntu
22.04.2
LTS
##[endgroup]
##[group]Runner Image
Image: ubuntu-22.04
Version: 20230402.1
Included Software: https://github.com/actions/runner-images/blob/ubuntu22/20230402.1/images/linux/Ubuntu2204-Readme.md
Image Release: https://github.com/actions/runner-images/releases/tag/ubuntu22%2F20230402.1
##[endgroup]
##[group]Runner Image Provisioner
2.0.139.1
##[endgroup]
Current image version: '20230402.1'
Agent running as: 'vsts'
Prepare build directory.
Set build variables.
Download all required tasks.
Downloading task: CmdLine (2.212.0)
Checking job knob settings.
   Knob: DockerActionRetries = true Source: $(VSTSAGENT_DOCKER_ACTION_RETRIES) 
   Knob: AgentToolsDirectory = /opt/hostedtoolcache Source: ${AGENT_TOOLSDIRECTORY} 
   Knob: AgentPerflog = /home/vsts/perflog Source: ${VSTS_AGENT_PERFLOG} 
   Knob: ContinueAfterCancelProcessTreeKillAttempt = true Source: $(VSTSAGENT_CONTINUE_AFTER_CANCEL_PROCESSTREEKILL_ATTEMPT) 
Finished checking job knob settings.
Start tracking orphan processes.
##[section]Finishing: Initialize job
##[section]Starting: Checkout Dev Wiki@master to s
==============================================================================
Task         : Get sources
Description  : Get sources from a repository. Supports Git, TfsVC, and SVN repositories.
Version      : 1.0.0
Author       : Microsoft
Help         : [More Information](https://go.microsoft.com/fwlink/?LinkId=798199)
==============================================================================
Syncing repository: Dev Wiki (Git)
##[command]git version
git version 2.40.0
##[command]git lfs version
git-lfs/3.3.0 (GitHub; linux amd64; go 1.19.3)
##[command]git init "/home/vsts/work/1/s"
hint: Using 'master' as the name for the initial branch. This default branch name
hint: is subject to change. To configure the initial branch name to use in all
hint: of your new repositories, which will suppress this warning, call:
hint: 
hint:   git config --global init.defaultBranch <name>
hint: 
hint: Names commonly chosen instead of 'master' are 'main', 'trunk' and
hint: 'development'. The just-created branch can be renamed via this command:
hint: 
hint:   git branch -m <name>
Initialized empty Git repository in /home/vsts/work/1/s/.git/
##[command]git remote add origin https://brbernardo.visualstudio.com/Dev%AZP2520Wiki/_git/Dev%AZP2520Wiki
##[command]git config gc.auto 0
##[command]git config --get-all http.https://brbernardo.visualstudio.com/Dev%AZP2520Wiki/_git/Dev%AZP2520Wiki.extraheader
##[command]git config --get-all http.extraheader
##[command]git config --get-regexp .*extraheader
##[command]git config --get-all http.proxy
##[command]git config http.version HTTP/1.1
##[command]git --config-env=http.extraheader=env_var_http.extraheader fetch --force --tags --prune --prune-tags --progress --no-recurse-submodules origin --depth=1 +ef8b3e859aedc2469c92a222fdf63fce2497ecc2:refs/remotes/origin/ef8b3e859aedc2469c92a222fdf63fce2497ecc2
remote: Azure Repos        
remote: 
remote: Found 45 objects to send. (0 ms)        
From https://brbernardo.visualstudio.com/Dev%20Wiki/_git/Dev%20Wiki
 * [new ref]         ef8b3e859aedc2469c92a222fdf63fce2497ecc2 -> origin/ef8b3e859aedc2469c92a222fdf63fce2497ecc2
##[command]git --config-env=http.extraheader=env_var_http.extraheader fetch --force --tags --prune --prune-tags --progress --no-recurse-submodules origin --depth=1 +ef8b3e859aedc2469c92a222fdf63fce2497ecc2
remote: Azure Repos        
remote: 
remote: Found 0 objects to send. (0 ms)        
From https://brbernardo.visualstudio.com/Dev%20Wiki/_git/Dev%20Wiki
 * branch            ef8b3e859aedc2469c92a222fdf63fce2497ecc2 -> FETCH_HEAD
##[command]git checkout --progress --force refs/remotes/origin/ef8b3e859aedc2469c92a222fdf63fce2497ecc2
Note: switching to 'refs/remotes/origin/ef8b3e859aedc2469c92a222fdf63fce2497ecc2'.

You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by switching back to a branch.

If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -c with the switch command. Example:

  git switch -c <new-branch-name>

Or undo this operation with:

  git switch -

Turn off this advice by setting config variable advice.detachedHead to false

HEAD is now at ef8b3e8 update
##[section]Finishing: Checkout Dev Wiki@master to s
##[section]Starting: CmdLine
==============================================================================
Task         : Command line
Description  : Run a command line script using Bash on Linux and macOS and cmd.exe on Windows
Version      : 2.212.0
Author       : Microsoft Corporation
Help         : https://docs.microsoft.com/azure/devops/pipelines/tasks/utility/command-line
==============================================================================
Generating script.
Script contents:
echo "hello to my first pipeline"
========================== Starting Command Output ===========================
[command]/usr/bin/bash --noprofile --norc /home/vsts/work/_temp/caf7686d-81a0-417e-86b7-0a7f102f78ce.sh
hello to my first pipeline
##[section]Finishing: CmdLine
##[section]Starting: Checkout Dev Wiki@master to s
==============================================================================
Task         : Get sources
Description  : Get sources from a repository. Supports Git, TfsVC, and SVN repositories.
Version      : 1.0.0
Author       : Microsoft
Help         : [More Information](https://go.microsoft.com/fwlink/?LinkId=798199)
==============================================================================
Cleaning any cached credential from repository: Dev Wiki (Git)
##[section]Finishing: Checkout Dev Wiki@master to s
##[section]Starting: Finalize Job
Cleaning up task key
Start cleaning up orphan processes.
##[section]Finishing: Finalize Job
##[section]Finishing: Hello World for pipelines

As pipelines no Azure Pipelines utilizam arquivos descritivos baseados em YAML. Isso traz algumas facilidades diminuindo a complexidade.

Estarei trazendo mais alguns exemplos de YAMLs para o Azure Pipelines.

O que é uma pipeline?

Luiz Bernardo — Thu, 13 Apr 2023 14:47:16 +0000

Para entender o que é pipeline precisamos dar um passo pra trás e entender o que é um comando.

A palavra comando tem significados diferentes no Linux: Um programa, um comando simples ou um comando combinado.

Um programa é um executável nomeado e executado com uma única palavra, como "ls";

Um comando simples é um argumento de um programa opcionalmente, como "ls -l /bin";

Um comando combinado se trata da saída de um comando simples ser utilizada para entrada de um novo comando simples, como "ls -l /bin | less".

Utilizamos o caractere combinador pipe para anotar o limite de um comando simples para que a saída dele seja utilizada no próximo comando.

Então, pipeline é uma linha de comando onde temos programas sendo utilizados na construção de comandos simples e a saída desse comando simples e utilizado na entrada de um outro comando simples criando os comandos combinados através do caractere pipe.

Criando AMI usando o Packer e Amazon Linux 2023 (AL2023) com o Azure Pipelines

Luiz Bernardo — Mon, 03 Apr 2023 13:52:21 +0000

Recentemente a AWS anunciou o novo sistema operacional da AWS baseado em Linux. Tem um comparativo super legal entre Amazon Linux 2 e Amazon Linux 2023 [nesse link](https://docs.aws.amazon.com/linux/al2023/ug/compare-with-al2.html).
Resolvi testar o novo sistema operacional criando a AMI com o Packer.

Packer HashiCorp é uma ferramenta de automação de criação de imagens de máquinas virtuais que permite criar imagens idênticas para múltiplas plataformas usando arquivos de configuração.

Para instalar o Packer, siga as etapas abaixo:

Acesse o site oficial do Packer: https://www.packer.io/downloads
Faça o download da versão do Packer compatível com o seu sistema operacional.
Extraia o arquivo ZIP baixado em uma pasta de sua escolha.
Adicione a pasta contendo o executável do Packer ao PATH do sistema para que possa ser acessado de qualquer lugar no terminal.
Para verificar se o Packer foi instalado corretamente, abra o terminal e digite o comando "packer version". Se a instalação foi bem-sucedida, a versão do Packer instalada será exibida.

Obs_1: As etapas exatas podem variar dependendo do sistema operacional em que o Packer está sendo instalado.

Obs_2: Essa etapa é apenas informativa, vou utilizar o Azure Pipelines no tutorial abaixo.

Assim como os outros produtos da HashiCorp ele utiliza o HCL2 como linguagem, mas nem sempre foi assim, antes ele utilizava json como linguagem e como ainda estão em fase de migração tem um how to de como fazer a migração para HCL2 [aqui](https://developer.hashicorp.com/packer/tutorials/configuration-language/hcl2-upgrade).

Você pode estar organizando o seu diretório packer com os arquivos abaixo, vamos ver o conteúdo de cada um deles.

├── packer
│    └── provider.pkr.hcl
│    └── builders.pkr.hcl
│    └── sources.pkr.hcl
│    └── variable.pkr.hcl
│    └── locals.pkr.hcl
├── install
│    └── nginx.sh
├── pipelines
│    └── azure_pipelines.yml

provider.pkr.hcl Contém informações sobre o tipo de provedor, como o nome da conta, região e outras configurações específicas do provedor. Vamos ao código:

#provider.pkr.hcl
packer {
  required_plugins {
    amazon = {
      version = ">= 1.2.2"
      source  = "github.com/hashicorp/amazon"
    }
  }
}

builders.pkr.hcl Contém informações sobre o tipo de máquina virtual que será criada, como sistema operacional, tamanho da memória, armazenamento e outras configurações relacionadas à infraestrutura. Vamos ao código:

#builders.pkr.hcl
build {
  name    = "ami-packer"
  sources = ["source.amazon-ebs.al-2023"]

  provisioner "shell" {
    environment_vars = ["FOO=hello world"]
    script           = "../install/nginx.sh"
    pause_before     = "10s"
    timeout          = "10s"
  }
}

sources.pkr.hcl Contém informações sobre o tipo de origem, como um arquivo ISO, uma imagem pré-existente ou uma receita do Chef. Vamos ao código:

#sources.pkr.hcl
source "amazon-ebs" "al-2023" {
  ami_name      = "${var.ami_prefix}-${local.timestamp}"
  instance_type = "t3.micro"
  region        = "us-east-1"
  source_ami_filter {
    filters = {
      name                = "al2023-ami-2023.*-kernel-6.1-x86_64"
      root-device-type    = "ebs"
      virtualization-type = "hvm"
    }
    most_recent = true
    owners      = ["amazon"]
  }
  ssh_username = "ec2-user"
  tags = {
    Name = "AMI 2023"
  }
}

variable.pkr.hcl Contém informações sobre o tipo de variável, como seu nome, tipo e valor padrão, que podem ser substituídos por um valor personalizado durante a execução do processo. Vamos ao código:

#variable.pkr.hcl
variable "ami_prefix" {
  type    = string
  default = "AMI"
}

locals.pkr.hcl E Um valor local atribui um nome a uma expressão , portanto, você pode usar o nome várias vezes em um módulo em vez de repetir a expressão. Vamos ao código:

#locals.pkr.hcl
locals {
  timestamp = regex_replace(timestamp(), "[- TZ:]", "")
}

Criei o diretório install apenas para organizar os scripts de instalação do que for interessante, no caso vou estar instalando o Nginx com um arquivo shell nginx.sh. Vamos ao código:

#nginx.sh
#!/bin/bash

# Atualiza os pacotes
sudo dnf update -y

# Instala o Nginx
sudo dnf install nginx -y

# Inicia o serviço do Nginx
sudo systemctl start nginx

# Habilita o serviço do Nginx para iniciar automaticamente na inicialização do sistema
sudo systemctl enable nginx

# Verifica o status do Nginx
sudo systemctl status nginx

Tudo certo, vamos agora ao Azure Pipelines.

Para organizar também criei um diretório chamado pipelines e inclui o arquivo azure_pipelines.yml. Vamos ao código:

#azure_pipelines.yml
trigger:
  branches:
    include:
    - master
pool:
  vmImage: Ubuntu-20.04
stages:
- stage: BuildAMI
  displayName: Build AMI
  jobs:
  - job: BuildAMI
    displayName: 'Build AMI with Packer'
    steps:
      - task: Bash@3
        displayName: 'Install Packer'
        inputs:
          targetType: 'inline'
          script: |
              echo "# Downloading Packer v1.8.6"
              wget https://releases.hashicorp.com/packer/1.7.6/packer_1.7.6_linux_amd64.zip
              echo "# Unzipping files"
              unzip packer_1.7.6_linux_amd64.zip

              echo "# Configuring packer and checking version"
              export PACKER_PATH=$(which packer)
              ls -lha
              sudo mv packer $PACKER_PATH

              packer -v
      - task: AWSShellScript@1
        displayName: 'Build AMI'
        inputs:
          awsCredentials: aws-teste-dev
          regionName: $(AWS_REGION)
          scriptType: 'inline'
          inlineScript: |
            cd projects/PocPacker/packer
            packer init .
            packer build .

Em outro post eu explico com mais detalhes como executar uma pipeline no Azure Pipelines. Bora executar a pipeline.

Crie um repositório no Azure Repos

Para criar um novo repositório no Azure Repos, siga os seguintes passos:

Abra o seu projeto no Azure DevOps;
Selecione a opção Repositórios no menu lateral esquerdo;
Clique em Novo Repositório no canto superior direito;
Selecione o tipo de repositório que deseja criar (Git ou Team Foundation Version Control);
Defina as opções de configuração do repositório, como nome, descrição e visibilidade;
Clique em Criar para criar o novo repositório.

Após criar o repositório, você poderá cloná-lo localmente para trabalhar em sua máquina, além de adicionar, editar e remover arquivos, criar ramificações e realizar outras operações de gerenciamento de código.

Tudo certo, é só enviar o código para o Azure Repos

Faça o download e instale um cliente de controle de versão de sua preferência, como o Git ou o Azure Repos Extension para o Visual Studio;
Inicialize um repositório Git em seu projeto local, se ainda não tiver feito isso, usando o comando "git init";
Adicione os arquivos e pastas ao seu repositório local usando o comando "git add";
Grave suas alterações locais no repositório usando o comando "git commit";
Conecte seu repositório local ao repositório remoto no Azure Repos usando o comando "git remote add origin ";
Empurre suas alterações locais para o repositório remoto usando o comando "git push origin "

Por último, vamos criar o pipeline no Azure Pipelines.

Selecione o projeto que deseja configurar o pipeline;
Clique em "Pipelines" no menu à esquerda e depois em "New Pipeline";
Escolha o repositório que contém o código do seu projeto (GitHub, Bitbucket, Azure Repos, etc);
Selecione o template do pipeline que deseja utilizar (como .NET Core, Node.js, Python, etc) ou comece do zero;
Configure o pipeline, adicionando tarefas, definindo variáveis, configurando gatilhos e definindo opções de agendamento;
Salve e execute o pipeline.

Agora é só acompanhar o andamento.

Criei uma instância EC2 para ver se está tudo ok a partir da imagem que criamos.

Espero que tenha gostado, criei um repositório no github com todo código utilizado https://github.com/brbernardo/packer

Vlw flw.

Abordagem Innersource nas organizações

Luiz Bernardo — Wed, 29 Mar 2023 14:17:29 +0000

Innersource é uma abordagem para o desenvolvimento de software que aplica conceitos de código aberto para projetos internos de uma empresa. Isso significa que as equipes de desenvolvimento compartilham seu código e colaboram uns com os outros, assim como acontece em projetos de código aberto. O objetivo é aproveitar a colaboração e a inovação que ocorrem em projetos de código aberto e aplicá-los a projetos internos.

Algumas das vantagens do innersource incluem:

Melhoria da colaboração entre equipes
Aumento da reutilização de código
Melhoria da qualidade do código
Redução de duplicação de esforços
Aumento da transparência e da responsabilidade

O innersource é uma abordagem que pode ser útil para empresas que desejam aproveitar as vantagens da colaboração e do código aberto, mas que precisam manter algum grau de controle sobre seus projetos internos. No entanto, implementar o innersource pode ser desafiante, pois requer mudanças nas culturas e processos da empresa, bem como em sua abordagem para o desenvolvimento de software.

O GitHub mantem um material bem legal sobre o assunto =D

https://resources.github.com/innersource/fundamentals/

Alem disso existe a comunidade InnerSource Commons que foca em discuções e volução do tema.

https://innersourcecommons.org/

Para participar ativamente você pode utilizar o slack da comunidade: innersourcecommons.slack.com

Por ultimo, e mantida uma pesquisa para entender a evolução do tema chamada State of InnerSource, a ultima edição ocorreu em 2021 e pode ser acessada por esse link

Migrando repositorio Git

Luiz Bernardo — Wed, 22 Mar 2023 11:26:21 +0000

Com as constantes aquisições de empresas no mercado de TI é bem comum ter que migrar o repositório de código que estava em um repositório remoto para outro, às vezes em produtos diferentes.

Pensando no cenário de migração de repositório remoto de soluções diferentes, do GitHub para o Azure Devops, por exemplo, a migração pode se tornar um pouco mais complexa. Veja, você precisa migrar o histórico do projeto por completo com branchs, tags e notes.

Primeiro, crie o repositório de destino para nossa migração, vamos utilizar ele no script.

Para isso criei um pequeno script bash na qual vou explicar aqui linha a linha antes de mostrar por completo, vejamos:

set -eufo pipefail

O comando "set -eufo pipefail" é um conjunto de opções que pode ser usado em scripts de shell, como o Bash, para modificar o comportamento padrão do ambiente do shell.

Uma explicação mais detalhada de cada uma das opções incluídas no comando:

"set -e": Encerra o script imediatamente caso um comando falhe ou retorne um status diferente de zero. Isso ajuda a evitar que erros passem despercebidos e ajuda a garantir que o script pare em caso de falha.
"set -u": Faz com que o shell gere um erro caso uma variável não definida seja referenciada. Isso pode ajudar a evitar erros que possam ocorrer quando uma variável é usada sem ter sido previamente inicializada.
"set -f": Desativa a expansão de nomes de arquivos com caracteres curinga (como * e ?), o que pode ser útil em scripts que lidam com arquivos com nomes não convencionais ou que podem conter espaços ou outros caracteres especiais.
"set -o pipefail": Faz com que um pipeline (comando composto por vários comandos conectados com o operador |) retorne o status de saída do último comando que falhou, em vez de retornar o status de saída do último comando executado com sucesso. Isso pode ser útil em pipelines complexos, onde é importante detectar falhas em qualquer ponto do pipeline.

O comando "set -eufo pipefail" ajuda a garantir que o script seja executado de forma confiável e consistente, evitando erros comuns que podem levar a falhas ou a comportamentos inesperados. Ele é especialmente útil em scripts que executam tarefas críticas ou lidam com dados sensíveis, onde a confiabilidade é essencial.

SOURCE_URL=https://repositorio_git_origem.git
TARGET_URL=https://repositorio_git_alvo.git

SOURCE_URL será a URL Git do repositório que queremos copiar
TARGET_URL será a URL Git do repositório alvo que queremos que fique igual ao repositório da SOURCE_URL

WORKDIR=./repos

Apenas para organização criei um diretório de trabalho local.

echo "Cloning from ${SOURCE_URL} into ${WORKDIR}..."
git init --bare "${WORKDIR}"
cd "${WORKDIR}"

O –bare cria um repositório vazio. Se GIT_DIRo ambiente não estiver definido, ele será definido no diretório de trabalho atual. Ao incializar um repositório como bare não será permitido editar arquivos (git add) e commitar mudanças (git commit), já que o mesmo não possui uma working tree.

Utilizo o –bare para garantir que não tenha nenhuma mudança no meio do processo de migração.

git config remote.origin.url "${SOURCE_URL}"

Esse comando é utilizado para definir a URL de um repositório Git remoto

git config --add remote.origin.fetch '+refs/heads/*:refs/heads/*'

O comando git config --add remote.origin.fetch adicionam uma nova configuração no git para o repositório atual.

O parâmetro --add diz ao git para adicionar essa configuração em vez de substituir configurações existentes.

remote.origin.fetch define o nome da configuração que está sendo adicionada. Essa configuração especifica como o Git deve buscar as alterações dos ramos do repositório remoto (chamado de "origin").

O valor '+refs/heads/:refs/heads/' é uma expressão que especifica que o git deve buscar todas as branches (ramificações) do repositório remoto. O primeiro * representa todas as branches no repositório remoto, e o segundo * representa todas as branches locais no repositório local. O sinal de + antes de refs/heads/* indica que, além de buscar os branches existentes, também deve-se adicionar novos branches que possam ser criados no repositório remoto.

Essa configuração diz ao git para buscar todas as branches do repositório remoto chamado "origin" e adicioná-las ao repositório local.

git config --add remote.origin.fetch '+refs/tags/*:refs/tags/*'

O sinal de + antes de refs/tags/* indica que, além de buscar as tags existentes, também deve-se adicionar novas tags que possam ser criadas no repositório remoto.

Essa configuração diz ao git para buscar todas as tags do repositório remoto chamado "origin" e adicioná-las ao repositório local.

git config --add remote.origin.fetch '+refs/notes/*:refs/notes/*'

O sinal de + antes de refs/notes/* indica que, além de buscar as notas existentes, também deve-se adicionar novas notas que possam ser criadas no repositório remoto.

Essa configuração diz ao git para buscar todas as notas do repositório remoto chamado "origin" e adicioná-las ao repositório local.

git config remote.origin.mirror true

A opção mirror é usada para especificar se o repositório local deve espelhar todos os dados do repositório remoto. Quando essa opção é definida como true, isso indica que todas as alterações feitas no repositório remoto devem ser automaticamente sincronizadas com o repositório local.

Quando essa opção está ativada, todas as operações de push, fetch e pull serão direcionadas ao repositório remoto origin, e o repositório local será atualizado automaticamente para refletir todas as alterações no repositório remoto, ou seja, define que o repositório remoto origin deve ser espelhado no repositório local e que todas as alterações no repositório remoto devem ser automaticamente sincronizadas com o repositório local.

git fetch --all

Este comando é usado para atualizar todas as referências de um repositório local com as alterações mais recentes do repositório remoto.

O parâmetro --all indica que o comando deve buscar atualizações para todas as branches (ramificações), tags e notas no repositório remoto.

Quando executado, o comando git fetch --all irá buscar todas as alterações no repositório remoto, mas não as mesclar automaticamente com a branch atual. Em vez disso, ele atualizará as referências locais para refletir as alterações mais recentes no repositório remoto.

Isso é útil quando você deseja verificar o estado atual do repositório remoto sem mesclar as alterações com seu repositório local.

echo ""
echo "Cloned to ${WORKDIR}; pushing to ${TARGET_URL}"

Apenas um print para deixar tudo mais visual

git push --mirror "${TARGET_URL}"

Ao executar o comando git push --mirror "${TARGET_URL}", o Git irá enviar todas as alterações do repositório local para o repositório remoto especificado, sobrescrevendo quaisquer alterações existentes e excluindo referências que não existem mais no repositório local.

echo ""
echo "Cleaning up temporary directory ${WORKDIR}..."

Mais anotações para deixar visível a conclusão da execução.

rm -rf "${WORKDIR}"

Remoção do diretorio de trabalho.

Com isso passamos por todos os comandos do script e seu repositório foi migrado na íntegra =D

Abaixo o script completo.

echo "Done."

bla bla bla
#!/bin/sh

set -eufo pipefail

SOURCE_URL=https://repositorio_git_origem.git
TARGET_URL=https://repositorio_git_alvo.git
WORKDIR=./repos

echo "Cloning from ${SOURCE_URL} into ${WORKDIR}..."

git init --bare "${WORKDIR}"
cd "${WORKDIR}"

git config remote.origin.url "${SOURCE_URL}"
git config --add remote.origin.fetch '+refs/heads/*:refs/heads/*'
git config --add remote.origin.fetch '+refs/tags/*:refs/tags/*'
git config --add remote.origin.fetch '+refs/notes/*:refs/notes/*'
git config remote.origin.mirror true
git fetch --all

echo ""
echo "Cloned to ${WORKDIR}; pushing to ${TARGET_URL}"

git push --mirror "${TARGET_URL}"

echo ""
echo "Cleaning up temporary directory ${WORKDIR}..."

rm -rf "${WORKDIR}"

echo "Done."