Como dominar o Bitbucket Pipelines para integração contínua e implantação contínua

1. Introdução: Olá a todos. Este curso trata de dominar pipelines Bitbucket para integração contínua e implantação contínua. Eu estava olhando em torno de compartilhamento de habilidades e eu percebi que não havia cursos especificamente para pipelines Bitbucket. Você bolso pipelines é para eu basicamente usar todos os dias como parte do meu fluxo de trabalho de desenvolvimento. E agora que eu tenho usado isso por um tempo e basicamente viciado, isso me poupa muito tempo de coisas que eu costumava fazer manualmente. Por isso espero poder partilhar convosco minha experiência e tudo o que aprendi ao longo do caminho. Assim, o u2 pode se beneficiar economizando muito tempo na automatização de coisas como seus testes, sua implantação e seus processos de compilação. Então vamos dar uma olhada no que vamos passar neste curso. Antes de trabalhar com pipelines diretamente, vamos configurar nosso ambiente e NodeJS e começar usando um repositório simples de placa de caldeira, criaremos um arquivo YAML de pipelines Bitbucket muito básico. Para iniciar a nossa primeira compilação, irá adicionar complexidade ao nosso faturado usando algumas etapas personalizadas para construir a fonte do site e, em seguida, usar sep para implantar o que são conhecidos como artefatos para nosso servidor de escolha vai ficar ainda mais complexo, adicionando funcionalidades SSH e chaves de acesso para que possamos fazer algum trabalho automatizado no lado do servidor, irá ramificar o repositório Git em um desenvolvimento, preparação em Master System e aprender a usar dinamicamente variáveis em cada ramo será também integram notificações personalizadas do Slack e até tente alguns mecanismos de auto-recuperação para quando as coisas dão errado com a implantação. partir daí, o céu é o limite para o que você quer fazer com suas próprias construções, implantações e testes. Espero que o curso pareça interessante para você, e espero que você se junte a nós em menos de um, onde veremos como é rápido e fácil começar com pipelines. Eu também quero mencionar que este curso é voltado mais para desenvolvedores intermediários e superiores. Então, desenvolvedores que já têm alguma experiência com repositórios Git e scripts bash. Vamos começar simples e ficar mais complexos, mas eu só quero que você saiba disso. Então eu acho que nós vamos nos divertir muito neste curso e espero vê-lo lá. 2. Configuração de ambiente: Antes de começarmos a codificar, devemos ter certeza de que estamos usando as mesmas ferramentas. Uma vez que estaremos usando um pouco de nó, vamos nos certificar de que nossas versões de nó são as mesmas. Então, se eu verificar a versão MyNode, estou usando a última versão dez, que é 10.19. E NPM também está aqui, 6.13.4. Se você não tiver esta versão, você pode instalar o nvm. E então você iria executar nvm install v 10.19. Meu caso, é claro que já instalei, mas isso irá instalar o nó e o NPM para você. Isso é meio fora do escopo deste curso. Mas se você for para a página do NVM GitHub, você pode ir até a instalação e atualização. Eles têm um script bash que lhe dará a versão mais recente. Se estiver a utilizar o Windows, terá de instalar o nó da origem, a versão 10.19. Então, para este curso, eu já preparei um repositório git simples que podemos usar como exemplo para construir nosso primeiro pipeline. Então podemos clonar isso agora. E vou colocar este link nas notas da lição. Vamos CD nessa pasta e abri-la no código do Visual Studio. Parece que há muita coisa aqui. Mas realmente tudo o que é é uma cópia do boilerplate HTML5, que é um bom modelo bare-bones onde você pode começar a prototipagem e construir um wireframe para um site sem ter que se preocupar escolher um framework como Reagir ou ver ou o que for. Basicamente, se você sabe, CSS normalizado, ele tem que lá e algumas outras guloseimas que basicamente unifica os estilos se você visitar a página em qualquer navegador. Então, quando baixamos isso, vemos que temos apenas um arquivo zip. E quando desempacotamos, temos as mesmas pastas que tenho no meu projeto. Então, se voltarmos ao projeto, vemos o mesmo tipo de estrutura. A única coisa que eu adicionei aqui, se entrarmos em índice, Eu adicionei bootstrap para alguns estilos. E, a partir daqui, isto é, isto é, isto é, isto é, isto é, isto é, isto é, a partir da placa , adicione o seu site ou aplicativo algodão aqui, todo o caminho até a tag de análise do Google, que também não está preenchida. Mas isso é apenas um conteúdo simples. E podemos abrir isso no navegador. E vemos que temos um site básico para trabalhar. Sem JavaScript, sem framework front-end. E é um pouco responsivo. Tenho certeza que vocês podem encontrar algo que não é perfeitamente responsivo aqui, mas é bom o suficiente para começar. E vai se adequar ao seu propósito para o que vamos fazer. Então, nesta lição, a primeira coisa que fizemos foi garantida que todos nós estamos usando a mesma versão do Node, reutilizando o nó versão 10.19. Em seguida, baixamos um repositório git de exemplo simples, que usaremos ao longo do curso. Como vimos, é uma cópia simples do caldeirão HTML5. E eu adicionei alguma marcação para o índice HTML e também para folhas de estilo para um do bootstrap e um do meu próprio. Então, na próxima lição, vamos começar e finalmente construir nosso oleoduto. 3. Criando seu primeiro Pipeline: Então a primeira coisa que precisamos fazer é criar um repositório Bitbucket, embora clonemos o repositório inicial do GitHub, teremos que criar um repositório aqui e depois transferir a URL de origem do repositório para o repositório criado aqui em Bitbucket. Então, se você não tem uma conta Bitbucket, você pode criar uma agora, ela é gratuita. E depois de ter sua página de visão geral do painel, você pode ir para Criar repositório. E eu vou pegar o mesmo nome do do GitHub. E nós criamos. Então temos a nossa URL. Note que será diferente com base no seu nome de usuário. E queremos copiar tudo, mas não incluindo a parte git clone do comando. Só queremos a URL. Então, podemos verificar a URL atual do repositório que acabamos de clonar com git remoto dash V. E vemos esse URL do GitHub. Vamos atualizá-lo com nosso URL Bitbucket que acabou de ser criado. Ou seja, você pode verificar se ele funciona emitindo o mesmo comando remoto git. Então, agora que nosso controle remoto está definido, podemos finalmente criar nosso arquivo pipeline. E esse arquivo tem que ser chamado de pipelines de bucket. Yml. Tanto quanto eu sei, um arquivo de pipeline sempre começa com os pipelines de comando. Então você define ramificações. Como veremos em outras lições no curso, é útil ter diferentes pipelines com base em qual ramo você está. Por exemplo, você pode ter um ambiente de teste ou teste e, em seguida, você tem seu ambiente ao vivo ou de produção. E o pipeline terá que ser executado de forma diferente com base nessas ramificações. Então, se alguns de vocês entraram no repositório, devem ter notado que eu já nomeei o ramo inicial que clonamos a lição um. E você pode verificar isso executando git branch para S V. E você pode ver se em menos de um. Então, em nosso arquivo pipeline, queremos notar que com menos de um. Agora podemos adicionar o que é conhecido como um passo. E podemos adicionar um nome para o nosso passo. E um roteiro. Agora, em oleodutos, bash está sempre disponível para você. Por enquanto, vamos fazer um simples eco. Olá mundo. Salve esse arquivo, vai adicionar tudo. Git commit com uma mensagem. Só para testar o pipeline. E vamos empurrar isso. Ótimo. No repositório dos lados. Se você vai para a guia do pipeline e você rolar para baixo, porque foi a primeira vez que empurrou um arquivo de pipelines bit bucket YAML, temos esse tipo de visão. No nosso caso, configuramos corretamente. E assim Bitbucket está nos dizendo que a configuração parece boa. E podemos dispará-lo aqui. Se você perdeu um comando ou um recuo, pode parecer algo parecido com isso. Diz que é inválido. E você terá um ponto amarelo onde você pode pairar. Aqui diz indentação ruim, mas às vezes pode dizer comando desconhecido ou algo não é reconhecido. Realmente 99% das vezes é por causa do recuo. E, na verdade, há uma ferramenta muito legal que você pode validar. Se você estiver realmente perplexo. Você pode copiar e colar continuamente o arquivo de pipelines aqui até que ele diga que é inválido. Então, se resolvermos isso apenas para mostrar como um exemplo, válido. E, novamente, estes são inválidos. Então você pode puxar por aqui com seu oleoduto até que seja válido. E você sempre pode copiar isso e colá-lo aqui. Certo, então vamos ativar oleodutos. E de imediato, a nossa primeira construção está a disparar. Ótimo. Então foi bem sucedido. A coisa realmente legal com pipelines é que você obtém um registro de cada passo que ocorreu. Estes são incorporados a configuração e desmontagem. No entanto, vemos que este é o nosso comando personalizado. Temos o comando real no pipeline e o resultado desse comando. Então vamos ver como isso é útil mais tarde na depuração quando há erros no pipeline ou algo der errado no servidor. Então, nesta lição, criamos nosso primeiro arquivo de pipeline com apenas um eco simples. Inicializamos isso através da aba oleodutos. Vimos os eventos de registro. E também vimos como você pode validar seus pipelines Bitbucket com este validador de pipelines Bitbucket, que publicarei nas notas da lição. Agora que nosso pipeline está ligado ao bitbucket, podemos começar a criar exemplos mais complexos e passaremos para isso na próxima lição. 4. Usar SCP, o SCP, para transportar artefatos da criação: Então, agora vamos analisar como implantar o que são chamados de artefatos em nosso pipeline Bitbucket. E artefatos são realmente nada mais do que arquivos e pastas especialmente definidos que Bitbucket sabe para manter uma cópia e que você pode manipular mais tarde. Então, realmente há dois passos principais neste processo de setembro. O primeiro é produzir os artefatos e dizer ao Bitbucket que esses são os artefatos. E o segundo é copiar esses artefatos para o servidor de destino. Neste caso, usarei uma gota Digital Ocean, que é apenas uma caixa remota do Linux. Portanto, os artefatos são especialmente úteis em processos de construção que produzem apenas conteúdo estático. Por exemplo, Criar aplicativo Reagir ou uma compilação de script de tipo. E também são úteis para quando a compilação é particularmente computacionalmente pesada ou lenta. Eu tenho que usá-lo muito, por exemplo, porque a gota que mencionei é o menor tamanho. E eu acho que tentar executar comandos de compilação diretamente no servidor pode resultar em tempos limite e o servidor simplesmente não ter memória suficiente para fazer a compilação. Portanto, antes de escrevermos qualquer comando no pipeline, queremos criar um novo ramo chamado Lição dois. Se você quiser acompanhar, você pode criar a ramificação agora. Ou, se você quiser simplesmente pular para o código de trabalho final, você pode simplesmente alternar para esse ramo a partir da versão clone do GitHub que tem o código-fonte completo. Então vamos fazer isso agora. Lição de checkout do Git. Ótima. Então podemos ver ramificações apenas para verificar duas vezes ou em menos de duas. Ok? E novamente, estamos trabalhando com esta base de código HTML5 estático. Assim, ele pode ser servido apenas servindo índice HTML por si só. E para simular um tipo de processo falso de construção, vamos definir uma pasta chamada dist. E como em qualquer framework onde você teria um disco ou pasta de compilação, por exemplo, com uma compilação de script de tipo ou aplicativo Criar Reagir, você deseja ignorar esse arquivo. Em obter. Não queremos comprometer os arquivos produzidos em nosso repositório. Então também vamos criar um novo arquivo gitignore e simplesmente adicionar dist para que possamos voltar ao nosso pipeline. E agora que estamos na lição de ramificação, precisamos definir que o nome da ramificação e definir nossa etapa artefatos. Então eu vou chamá-lo de nome como um processo de construção um tanto falso. Só para simular novamente que estamos, estamos movendo alguns arquivos para nossa pasta dist, que são a compilação real. Ficheiros, porque estamos apenas a simular esta lei. Tudo o que temos que fazer é copiar toda a base de código para esta pasta dist. Então, no início, você pode pensar em usar Cp como um simples comando bash para fazer isso. Mas nós não queremos realmente copiar a pasta dist em si para dist. E então você vai, você vai entrar em um loop basicamente recursivo e ele não vai funcionar. Então, há uma boa alternativa para usar nossa pia onde você pode evitar esse loop recursivo. E então o que podemos fazer é o nosso traço de sincronização AB, obter a barra de progresso. E esta é a fonte, então a raiz do projeto. E queremos copiá-lo para dist. Mas queremos excluir isso. Então esse comando deve fazê-lo. E então precisamos, claro, definir artefatos E, que serão dist e todos os arquivos e subpastas. Então estrela dupla. Portanto, normalmente nesta etapa de script em um, usando um, uma estrutura como Node ou script de tipo, você executaria instalação de nó e construção de nó, teste de nó. Aqueles comandos ficariam ali. E então você ainda definiria seus artefatos. E você também pode definir vários artefatos se você tiver mais do que apenas um único diretório. Por exemplo, se você tivesse algum outro arquivo TXT de saída, por exemplo, você os listaria continuamente após esse identificador de artefatos. E, em seguida, é claro, há um segundo passo que é realmente implantar essa pasta de disco para o servidor. Então, vamos nomear isso. Oops. E o roteiro aqui é um pouco especial. Na última cena tem um construído em SCP em que você pode usar que é este. E então você também precisa definir as variáveis para este comando scp. Opa. Então você precisa de um servidor de usuário. O caminho remoto, que vou colocar na fonte web Linux padrão sob uma pasta chamada Skills share SEP test. E o caminho local é relativo a essa base de código ou ao próprio repositório, que é dist. E também queremos todos os arquivos e pastas. Então esses dois passos devem nos levar com o SEP. A única coisa que falta agora é que nós realmente temos que configurar como CP, então ele vai funcionar. Então, há duas coisas lá. Primeiro precisamos definir o usuário de destino e servidor para onde queremos implantar. E também precisamos configurar as chaves SSH. Então Bitbucket tem acesso ao nosso servidor. Então, indo para a nossa página de repositórios, queremos ir para as configurações do repositório. E primeiro vamos adicionar essas variáveis do Repositório, o usuário e o servidor. E eu também devo mencionar que isso sempre que você tem um cifrão com um nome de variável, isso é dizer ao Bitbucket para olhar nesses pares de valores-chave das variáveis do repositório. Então, por enquanto só precisamos do usuário e do servidor, mas você pode teoricamente adicionar quantos precisar. E, claro, estes são muito úteis para, para coisas como esta, onde a segurança e a privacidade são importantes e você não quer codificar esses valores diretamente em seu pipeline. Então, para a minha configuração, eu sou raiz. Você pode ter protegido no servidor. Eu também vou colar aqui, e eu também vou torná-lo seguro. Certo, temos nossas variáveis de servidor e usuário, e agora precisamos configurar a chave SSH. A maneira mais fácil de fazer isso é apenas ter bucket gerar as chaves para você. Então, vamos clicar nisso. E o bitbucket cria um par de chaves públicas privadas. E eles até te dizem exatamente o que fazer. Copie esta chave pública para chaves autorizadas SSH no host remoto. Então vamos fazer isso agora. Então eu tenho um alias para fazer login diretamente na minha gotícula. Eu não quero revelar a minha epinefrina e acesso lá, mas pelo menos você vê aqui você pode ver root que era nosso usuário. E nós vamos para esse caminho. E abriremos o arquivo de chaves autorizadas. Então eu já tenho algumas chaves públicas aqui, algumas são para, então eu já tenho algumas chaves públicas aqui, algumas das quais são na verdade para outros projetos de pipeline Bitbucket. Então eu já tenho algumas chaves públicas aqui, algumas das quais já estão sendo usadas para diferentes pipelines de compilação em diferentes repositórios. Mas vamos colar o nosso aqui agora mesmo. Basta pressionar Enter. Olha, tudo bem. Saia com o controle X e salve. Mesmo arquivo. Ok, ótimo. Portanto, também é uma boa ideia buscar e validar a impressão digital dos hosts conhecidos. Então eu vou adicionar meu é o mesmo IP ou URL que você usaria nas variáveis, as variáveis de repositório para o servidor. E podemos buscar a impressão digital. E antes de adicionar o host, podemos saltar rapidamente no servidor e validar se isso está correto. Então, para fazer isso, novamente, eu vou SSH em minha caixa Linux. E para fazer isso, podemos escrever um simples bash for-loop para obter o hash md5 para todos os nossos arquivos de chave pública. Isso se parece com isso. E vou postar este comando nas notas do curso. Para que possamos olhar. Eu tenho este F9 EC e o 9171 F9 EC. Sim. Esse é o nosso hash ECDSA MD5. Então podemos ir em frente e adicionar este host. Uma última coisa que precisamos fazer, onde quer que você esteja servindo esses arquivos é garantir que esse diretório exista. Então vamos cd em Var www e criar esse diretório. possamos verificar isso como perfeito. Ok, e isso deve ser trabalho suficiente para agora que temos que fazer no servidor remoto. Então, agora que estamos de volta aqui em nosso repositório local, devemos ser capazes de empurrar o código como ele está agora no ramo inferior a dois. E deve executar os passos. Então vamos experimentá-lo. Adicione as nossas alterações. E então vamos nos comprometer com uma mensagem. Primeiro teste de SCP e empurre isso. Precisamos dizer ao controle remoto que a origem também deve ter menos de dois ramos. Então, se saltarmos para nossos oleodutos, podemos ver que foi bem sucedido. E novamente, a boa vantagem aqui é que temos o mesmo registro do console. Desde que passamos este sinalizador de progresso com o rsync, vemos o mesmo log que iríamos se executássemos esse comando localmente no repositório. E também implantar com êxito a pasta aqui. Então, para verificar novamente, vamos voltar para o nosso servidor. E novamente, nós colocá-los no teste SEP muito WW de compartilhamento de habilidade. E vamos listar o que temos aqui. Ótima. Portanto, este processo de compilação sob menos de dois ramificação está funcionando com sucesso. Estamos na nuvem, não localmente. Estamos na nuvem copiando todos esses arquivos para uma pasta de disco, que é definida como um artefato, e copiando o conteúdo dessa pasta para este caminho remoto. E ainda há um passo final que precisamos fazer no servidor. E isso é que nós temos que realmente servir esses arquivos e verificar se eles estão sendo servidos corretamente. Uma vez que fizermos isso, teremos uma integração contínua completa, embora simples. Então, na próxima lição, veremos como podemos SSH no servidor em nosso Build Pipeline e executar os comandos que precisamos para garantir que index.html esteja sendo servido. 5. Usando SSH para executar comandos no servidor: Então, na última lição, aprendemos como implantar artefatos em nosso servidor de produção. Agora precisamos executar alguns comandos adicionais para realmente servir os artefatos que implantamos para que possamos visualizá-los em um URL público. Então, novamente, a primeira coisa que precisamos fazer é nos ramificar em uma nova lição, ramo, lição três. E nós podemos realmente copiar os passos exatos da Lição 2, os dois primeiros passos. E vamos adicionar o nosso terceiro passo. Portanto, queremos servir este conteúdo estático. E, idealmente, você teria um servidor em execução constante, por exemplo, um servidor Express. E então você configuraria um proxy usando uma ferramenta como Apache ou motor X para expor isso. Chegaremos a esse tipo de coisas em futuras lições. Mas, por enquanto, só queremos mostrar como emitir comandos SSH para poder fazer isso. E duas ferramentas que tornam isso muito fácil são MPM servir manipulador e n pacotes Grob. E juntos poderemos servir esse conteúdo estático e também expô-lo à internet para que possamos visualizar nosso site em um URL público. Então eu já montei um arquivo index.js simples, que vou colocar nas notas da lição. Como é um tipo de fora do escopo deste projeto. Então nós vamos criar aqui, e eu vou apenas copiar e colar isso aqui. Basicamente, o que está acontecendo é que iniciamos um servidor usando o middleware manipulador de servir. E para os interessados, servir manipulador é o núcleo de servir, que é a maneira simples recomendada que você pode servir. Por exemplo, uma compilação de aplicativo Criar Reagir. Apenas uma CLI simples onde você diz servir o nome da pasta nessa pasta é servido, mas isso é o que está acontecendo em segundo plano. Isso é um middleware para o pacote padrão Node HTTP. E então eu passo dois, Eu conectar n grok para aquele porto e eu mantive 5 mil como Serve. O comando CLI serve usa 5 mil como padrão. Então eu só mantive que não há nenhuma razão especial. E fim grok vai expor o porto local 5 mil para a internet. Assim, com o nosso index.js configurado e está pronto para ser executado, agora podemos definir o terceiro e último passo para este processo de compilação. Então, novamente, Omega passo direito. E vou dar-lhe um nome bastante explícito. Servir estaticamente o manipulador do servidor e expô-lo à internet via raiva. Ok. E voltará a ter um guião aqui. E na última lição, uma vez que já definimos usuário e servidor, podemos, naturalmente, usá-los nesta etapa também para o nosso SSH, apenas SSH usuário no servidor. E então podemos pensar sobre o comando que precisamos emitir. Então primeiro precisamos chegar à raiz de onde nosso conteúdo estático está. Teste SCP de compartilhamento de habilidade. E vamos fazer E, e o que significa em série. Então, isso significa que bash garante que este comando seja concluído e, em seguida, passa para o próximo. Considerando que um único seria em paralelo. Mas CD é importante para nós estar no diretório primeiro antes de emitir este próximo comando, que é npm install. E vamos instalar as duas ferramentas que precisamos executar, nosso index.js, que é servir, manipulador e grok. E novamente, isso é algo que queremos fazer em série. Queremos esperar que ele termine. E então podemos executar o nó index.js. Podemos salvar isso. E se olharmos para index.js, podemos ver que eu coloquei alguns logs de console aqui. Então, seremos capazes de ver isso na interface de usuário de bitbucket. E no final do dia, vamos obter uma URL n grok e devemos ser capazes de visitar essa URL. Então algo é algum tipo de haxixe. E então n tenho que I0. Então vamos ver isso no bolso UI e seremos capazes de visitar isso e ver nosso site. Com sorte, vamos empurrar isso. Agora. Digamos que agora somos capazes de emitir comandos via SSH. E vamos empurrar. Ótima. E assim vemos que o túnel de queda está exposto aqui. Então, podemos clicar nisso. E ótimo, e nós temos nosso site. Enquanto esse terceiro passo final em nosso processo de implantação contínua funciona, há um ligeiro soluço nesse nó. Index.js nunca dar balde de cuspe um sinal o fim. E assim o processo de construção nunca percebe que ele é concluído. E isso é claro ruim se você estiver tendo um limite de minutos no ambiente de compilação Bitbucket. Então vamos introduzir uma nova ferramenta que pode executar esses processos em segundo plano e que é para sempre. Então, vamos simplesmente adicionar isso à nossa lista de pacotes para instalar localmente. E em vez de usar Node, emitimos para sempre iniciar index.js. Mas ao editar este comando, percebemos que há um problema diferente. E isso é assim que seu aplicativo cresce e você tem que fazer comandos mais complexos e talvez até mesmo considerar ambientes diferentes. Não podemos escrever um comando em linha e para o nosso Build Pipeline para sempre. E então uma boa maneira de refatorar isso é coletar esse script em um script bash. Então eu vou pegar isso e nós podemos criar um script bash chamado deploy. Cole isso. E podemos colocá-los em várias linhas para legibilidade. Salvando isso. Agora, em vez dessa grande cadeia de comandos, podemos simplesmente executar nosso script bash. Mas precisamos lembrar que esse script bash será movido para a pasta dist, que se torna a pasta estática raiz. Então, primeiro precisamos cd novamente nesta pasta de teste CP compartilhamentos de habilidade. E então podemos chamar Bash implantar SH. Bash Então, vamos adicionar que fatoração comandos SSH em script de implantação. Vamos empurrar. Ótima. Então nós vemos alguma saída de sempre. Mas é importante notar que perdemos isso e grok info. E também seria bom se nem sempre tivéssemos que vir à nossa interface do Bitbucket para ver os logs da nossa conta. Então devemos procurar uma maneira agradável de enviar mensagens e faremos exatamente isso na próxima lição. Onde nos conectaremos a uma folga comprada, onde podemos enviar mensagens do nosso processo de construção. 6. Criando um bot de mensagens do Slack para adicionar a funcionalidade de mensagem: Na lição anterior, construímos nossa primeira compilação completa de integração contínua. E no final da lição, lembramos alguns comandos do Bash em um script, que foi capaz de completar uma saída limpa para o Bitbucket. Mas vimos que perdemos algumas informações de registro. Mas, a longo prazo, sempre olhar para as informações de registro para informações críticas, como a URL publicada, é um pouco complicado. Por isso, queremos criar um sistema de mensagens para acessar essas informações mais facilmente e mais fácil de usar. Então vamos fazer isso criando uma folga comprada. Então eu já abri o URL, que é api dot slash.com barra de mensagens barra hooks web. E o primeiro passo é criar seu aplicativo Slack. Então eu vou clicar nisso. E eu já me conectei. Eu já tenho uma conta de folga. E chamarei isso de compartilhamento de habilidades. Implantar bop. E eu vou criar esse aplicativo. E queremos entrar em ganchos da web, podemos ativá-los. E o primeiro exemplo aqui já está no formato Bash. Então vamos adicionar um novo gancho web para que possamos obter esse URL. E eu vou criar rapidamente um novo canal chamado Teste de Compartilhamento de Habilidades. Acho que preciso. Vamos adicioná-lo ao canal de teste de habilidades compartilhadas, clique em Permitir. E ótimo, obtemos um URL web hook real. Então, como eu disse, isso já está no formato Bash. Então, podemos ir em frente e, como primeiro exemplo, ir direto para o nosso script de implantação. E vamos primeiro colocar isso como r. Podemos mudar o texto para começar CI ponto, ponto, ponto. Certifique-se de adicionar isso. E, e para continuar os comandos. E também vamos colocar o CI final completo. E não precisamos deste último dia e vamos poupar isso. E eu já fui em frente e criei uma lição para Branch. Por isso, temos de acrescentar isso. E a construção em si permanece exatamente a mesma. Nós só nos conectamos a este gancho web como um, como um efeito colateral. E então precisamos significar lição para, para este ramo. E devemos ser capazes de acrescentar isso. E agora que empurrámos, isso deve disparar sobre a construção. E devemos ver nossas mensagens em folga. Então vemos o informante inicial e vejo eu completar. Então nós nos amarramos em nosso script de implantação. Mas nosso objetivo original também era obter o link grok final do script index.js. E novamente, estou tentando manter este curso focado em oleodutos o mais possível. Então eu vou apenas colar no código aqui e descrever rapidamente o que eu fiz. Essencialmente, eu escrevi uma versão JS nó deste comando curl. Precisamos definir os cabeçalhos JSON aplicativo e passar os dados JSON como um valor-chave com texto e uma string. E, claro, postado para o URL fornecido. E então eu exigi o nó fetch pacote e criei uma função wrapper em torno dele, onde tudo que você tem a fazer é passar a mensagem string. Então temos postar nosso cabeçalho JSON aplicativo. E para o corpo que stringify com o valor chave, texto e mensagem. E para ilustrar que configurei a função ao lado do console.log. Na realidade, provavelmente podemos remover essas linhas console.log ou gravar em um arquivo de log local no servidor. Mas, por enquanto, vou deixá-la. Portanto, devemos ver como resultado ainda estas duas mensagens. E, em seguida, além disso. A corrida no host local 5 mil e n túnel grok. E vamos finalmente obter nossa URL em folga em porque eu adicionei nó fetch, vamos ter que adicionar isso ao nosso script de implantação como um pacote. E isso deve bastar. E podemos ver que estamos recebendo aqueles que eram anteriormente logs console agora uma folga mensagens. E mesmo que passemos isso, assim como uma string normal para folga, folga é inteligente o suficiente para reconhecer estes são URLs e formata-los para nós. Você pode até fazer outras coisas como passar emojis e fazer alguma formatação simples como negrito e itálico. Mas vou deixar isso para você olhar nas docas. Mas vamos verificar nosso link para ver se está funcionando. E perfeito. O local está em cima. Para aqueles de vocês que estão programando até agora. Você pode ter notado que há um pequeno problema com nosso script de implantação e nosso index.js. O problema é que esse script iniciará um processo de nó escutando em 5 mil. E quando emitimos para sempre iniciar index.js para sempre tentará iniciar uma nova instância de nó neste script. E isso vai realmente falhar porque já há um processo em 5 mil. E assim, neste caso, para sempre tem um bom comando em vez de começar a usar o reinício. E o bom aqui é que ele verificará se um processo nesta pasta com index.js já está em execução. Caso contrário, ele inicia-o, mas se estiver em execução, ele irá reiniciá-lo. Então, executando para sempre reiniciar. Vamos corrigir esse problema para uma última limpeza aqui. Devemos também mover este URL para uma variável de ambiente. Não é muito arriscado à segurança, mas se alguém receber esse link, ele pode enviar spam para seu canal de folga, o que seria um pouco irritante. Então, no caso de Node, podemos remover isso. E isso se tornaria algo como processado dot n dot Slack URL web. E também devemos fazer o equivalente no script de implantação. Então esses dois, vou renomear Slack, URL web hook. E, claro, essa sintaxe. Leve-nos de volta para as variáveis do repositório. Então, podemos adicionar esse URL do gancho web Slack e colar que em e também torná-lo seguro. E há um último passo que precisamos fazer. Portanto, a variável repositório não é diretamente utilizável aqui neste script, mas sim está disponível no arquivo Gamow de pipelines bitbucket. Então podemos passar isso como um argumento. E quando for passado para o script. Como é o padrão bash. O primeiro parâmetro é o cifrão um. E assim para usar o mesmo nome neste script, bem como no processo de nó. Podemos exportar uma variável o mesmo nome para ser equivalente a esse perímetro. E como Forever tem suas próprias variáveis de ambiente, também precisamos passar esse mesmo comando na frente da chamada para sempre. E essa sintaxe também não funcionará com reinicialização. Tem que ser com o início. E assim vamos fazer um par vai fazer primeiro Forever, parar index.js e vamos reiniciar com o parâmetro correto. Agora há uma última coisa a fazer. E isso é uma vez que estamos passando a variável repositório nesta string SSH, para que isso seja avaliado corretamente para a variável real, precisamos usar aspas duplas. E isso deve bastar. E podemos ver que o construído completou. E nós refatoramos isso com sucesso. E funciona exatamente da mesma forma. Vamos verificar esta mensagem mais recente. Ótimo, esse é o nosso site estático. E para ter certeza de que não há outro processo separado em execução, o que não esperaríamos. Isso deve levar a algum tipo de erro. Exactamente. Então n Grok não está mais correndo. Nesta URL. Com sucesso, criei um novo acesso ao nosso site neste URL mais recente. Então tudo parece estar funcionando. Então, nesta lição, refatoramos nosso URL de gancho de web de flack embutido para uma variável de repositório. E vimos que, para que isso seja acessível durante a execução no servidor, temos que passar isso usando aspas duplas na string SSH. E também temos que, é claro, definir essa variável, esse par de valores-chave na interface do usuário de variáveis de repositório no site bitbucket. Mesmo depois de passar nesta variável, que é o cifrão um, nós também tivemos que passá-la para sempre. E com este tipo de sintaxe, os parâmetros só podem ser definidos com start para sempre. Então fazemos um par de parar para sempre e começar para sempre. Então podemos ver que esse tipo de layout é um pouco complexo. E quando estamos trabalhando com uma estrutura mais complexa, como script de tipo, podemos tirar proveito de vários arquivos n, como um ambiente de desenvolvimento, ambiente de teste e um ambiente de produção. Para evitar esse tipo de pares de comandos, tudo fluirá de forma muito limpa a partir de um arquivo JSON de ambiente. 7. Bootstrapping com Crie React: Na última lição, melhoramos o envio de mensagens em certos pontos do pipeline através da folga. Mas vimos como é complicado lidar com apenas uma variável de repositório. E como é difícil quando estamos fazendo nossas próprias ferramentas. E ainda não nos afastamos daquele código HTML cinco Boilerplate original. Portanto, as técnicas de pipeline que usamos até agora são boas e os conceitos funcionarão com qualquer projeto. Mas devemos examinar o que podemos fazer com um exemplo mais complexo. Usando React e digite script. Podemos aproveitar as ferramentas que essas linguagens possuem e as ferramentas construídas em torno delas para tornar nossos pipelines ainda mais limpos. E também estaremos finalmente projetando um pipeline com uma construção real nesta lição. Nesse caso, o comando npm run build do aplicativo Create React. Primeiro para esta lição, vou criar três ramificações para simular um fluxo de trabalho completo de CD CI, que são desenvolvimento, preparação e mestre. Então vamos primeiro criar um Branch completamente vazio. Uma vez que não estaremos seguindo ou pegando qualquer código do nosso site HTML5. Então vamos criar um ramo órfão. E queremos começar com uma ficha limpa aqui. Então vamos remover todos esses arquivos. E ótimo, que sobrou, mas isso é ignorado de qualquer maneira. Para que eu possa me livrar disso também. Ok, e estamos prontos para inicializar com o aplicativo Criar Reagir. Então isso é n px. Criar aplicativo React. Deslocamento e ótimo. Então, o bootstrap do reator de criação terminou. E podemos empurrar tudo isso como nosso compromisso inicial para este novo projeto, por assim dizer. E também queremos ter certeza de que nossos ramos de encenação e mestre tiveram a mesma base de código para começar também. Ok, então desenvolva, Mestre, e encenação todos têm a mesma base de código. E tenha em mente que esta configuração é um pouco especial, já que eu quero manter todo o código do curso para você no mesmo repositório em um projeto normal, master é criado por padrão com git init. E assim você só teria que criar, desenvolver ramificação e ramificação de preparo. 8. Definir arquivos de ambiente e usar em um componente: Então vamos entrar em algum código aqui. Na última lição, estávamos preocupados com o malabarismo e a passagem de variáveis de repositório. Então, para fazer isso de uma maneira mais limpa, podemos definir alguns arquivos de ambiente para cada uma dessas ramificações que temos. Então, primeiro vou criar uma pasta final na pasta de origem. E eu vou colocar para arquivos de ambiente, padrão EN dot JSON e, e desenvolver ponto JSON encenação de Jason e Esther. E como um exemplo inicial simples, vamos colocar uma chave de nome do site em cada JSON. Então, para o desenvolvimento, diga algo como pense nisso como um título. Só por um exemplo para começar. Encenação seria como e também chamá-lo de site de testes. No mestre seria o local de produção. E, por enquanto, vamos tomar o desenvolvimento JSON como nosso JSON final. Então, temos esses vários ambientes, mas vai BB, o ponto n ponto normal JSON que usaríamos em todos os nossos componentes no resto do nosso aplicativo. E assim, por exemplo, se acontecer com o arquivo TSX do aplicativo, eu posso importar esse arquivo JSON, basta chamá-lo n. E o benefício com o Visual Studio Code e Type Script é que o script de tipo saberá o que você tem em seu AnyObject. Então você pode fazer algo como ele já sabe nome do site é uma propriedade lá. Então, para usar nosso ambiente de desenvolvedor localmente, podemos adicioná-lo ao comando pre start em package.json. E esta é uma convenção de nomenclatura npm, o que significa que antes de disparar o comando start, execute o que estiver no comando restart. E para isso, nós simplesmente queremos, isso é bash. Queremos copiar pn dot JSON para o arquivo principal. E agora se iniciarmos o NPM, pré start vai disparar. Ele irá copiar este desenvolvido em N, o que nós, nós já fizemos manualmente. Mas devemos ver no título, o local de desenvolvimento. Então vamos dar uma chance a isso. Ótima. Então meu título é desenvolvimento local local. 9. Como utilizar ambientes em um arquivo do Bitbucket: Certo, mas não estamos aqui para escrever scripts package.json. Estamos aqui para aprender sobre gasodutos bitbucket. Então vamos incorporar esses ambientes em nosso pipeline. Como estamos em um quadro totalmente novo, precisamos criar um novo arquivo de pipelines de bucket. E tudo começou como fizemos com o outro no exemplo original. E aqui normalmente você teria sua encenação e mestre. E então você teria seus comandos dentro. Mas como estamos usando essa configuração especial baseada em lições, temos esses nomes de ramificação. Assim como adicionamos ao comando pré start, que é para nós para desenvolvimento local. Queremos fazer exatamente a mesma coisa, mas com a encenação em ambientes mestre, respectivamente. Então, vamos dizer copiar ambiente de preparação também. O Jason. E o mesmo script, apenas um arquivo diferente. E encenando que Jason para fonte e JSON. E a mesma coisa aqui para Mestre e apenas indo para copiar colar e pegar aquele arquivo mestre. Portanto, uma vez que as variáveis estão fluindo deste arquivo final, é importante que este seja o primeiro passo ou um dos primeiros passos. Se estiver fazendo outras coisas. Antes de fazer qualquer construído, queremos que nossas variáveis sejam definidas corretamente antes de construir ou testar ou coisas assim. Então agora vamos realmente definir a construção de um artefato passos. Essencialmente os mesmos conceitos que com o nosso site estático simples. Mas é um pouco mais complexo porque também queremos enviar nossos módulos Node, bem como a pasta Build que reagem Criar, Reagir app cria. Então eu estou realmente indo para colar direito nas etapas que definimos antes em refator-los para este projeto de aplicativo Criar Reagir. Então, em vez de um processo de construção falso, vamos dizer um processo de construção real. E esse script é simplesmente npm run build. E temos alguns artefatos aqui. Teremos nossa pasta de compilação, que é padrão que Create React app tem. E a pasta de módulos MPM. E também que ainda não criamos, um servidor JS de índice. 10. Refatoração para o servidor ngrok para o projeto React TypeScript: E este servidor de índice JS, eu estou realmente indo pedir emprestado também do exemplo de site estático HTML5. Só porque eu acho que n grok torna muito fácil para obter o seu site em uma URL pública muito rapidamente e é ótimo para prototipagem. Então eu vou criar um index.js aqui como nosso arquivo de servidor. E eu também vou copiar isso, copiar e colar o exemplo em. Portanto, já podemos aproveitar nossos ambientes que criamos aqui. Em vez de definir uma porta fixa. Isso é algo que também podemos adicionar ao nosso ambiente JSON. Então eu vou substituir isso em todos os lugares com o enésimo porto ponto. E é claro que temos que importar isso. E devemos, claro, adicionar a nth chave. Podemos começar em 5.001 para desenvolver e depois subir. Novamente. Vamos manter que mestre é $5.3 encenando 502. E podemos até mesmo, você também pode adicionar como uma dica. E estes registos de consola. Esta outra modificação antes de estarmos usando o manipulador de servir diretamente no diretório de trabalho. Mas como vamos definir nosso pipeline, vamos colocar esse arquivo de servidor ao lado do diretório de compilação que é criado. E então há um terceiro parâmetro aqui, que é um objeto de opções. E essa opção é a opção pública, que é build. E há mais uma coisa que podemos adicionar também, novamente, aproveitando esses arquivos JSON de ambiente. E isso é isto. Temos a vantagem agora. Se quiséssemos criar vários URLs de folga para cada uma de nossas filiais, por exemplo, se você quisesse comprar para preparação e quisesse um bot para mestre, que você poderia colocar em canais separados. Você poderia fazer isso com esta configuração de ambiente. E assim, em vez de passar o valor real, passamos a chave da variável de ambiente dois, o ponto do processo n. E chamamos isso chave para significar que este é o nome da chave. Então, por exemplo, você teria para o desenvolvimento, ou talvez você, você pode nem mesmo ter um em desenvolvimento. Pode deixar isso vazio. Copie isso também. No mestre. Você pode chamá-lo, Vamos chamá-lo de Compartilhamento de Habilidades, pasta de trabalho mestre. E então para encenação, encenação, Slack web boat. Desta forma, você pode ter vários URLs ou manter o mesmo nome de chave e apenas manter o que já criamos. Vou salvar tudo isso. 11. Refatoração para o projeto React TypeScript: Vamos finalmente voltar ao oleoduto. Então definimos nossos artefatos. Refatoramos index.js para trabalhar com as variáveis de ambiente que temos. E agora temos que implantar cada um desses artefatos com SEP. E é importante que tenhamos uma pasta diferente aqui. Então agora eu vou chamar isso, vai ter um script de tipo. Vou chamá-lo de preparação de script do tipo Compartilhamento de Habilidades. E a compilação que queremos realmente colocar na pasta de compilação. Pasta de compilação. Em módulos NPM. Vamos encontrar erro lá nenhum Módulos também está ao vivo no mesmo nome de pasta. E o index.js. Vamos apenas ir na raiz desta pasta no servidor. E isso deve bastar. Podemos copiar esses quatro passos e usá-los para um mestre também. A única mudança aqui é que teremos uma pasta diferente chamada éster. Então, primeiro quero saltar para o meu servidor e garantir que essas pastas existam. Então eu vou fazer a pasta de teste e também a pasta mestre. E também dentro de cada um, eu preciso fazer o diretório de compilação e também o diretório de módulos de nó. Isso deve bastar. Posso sair do servidor. E o passo final aqui é adicionar uma imagem de nó. Então, antes de conseguirmos apenas usar scripts bash, porque tínhamos que fazer alguma manipulação de pastas com esses arquivos estáticos. Mas aqui estamos realmente executando a reconstrução do NPM na nuvem. Então Bitbucket precisa saber, bem, qual versão do nó você deseja usar? Caso contrário, ele usará seu padrão. Então, como eu disse no início do curso, estamos usando o nó 10.19. Essa é a diretiva de imagem dentro do arquivo de pipelines YAML. E também podemos adicionar no processo de construção sob o nome de diretiva de um cache e especificando nó. E isso significa que se já baixamos esta imagem para Node, e bitbucket vê que, em seguida, ele vai usar essa imagem. Ele não será baixado novamente todas as vezes. Assim, isso acelera seu processo de compilação e economiza minutos de compilação. Então eu também vou adicionar isso ao mestre. E um passo que eu quase esqueci no processo de compilação é realmente instalar os módulos NPM com instalação npm. Então adicione isso ao teste e ao build do ramo mestre. Então eu também percebi que eu estava escrevendo medo final. Esta deve ser a porta como a porta nth ponto, não n ponto n. Então deixe-me corrigir isso rapidamente. E eu também mudei o ambiente web hook Key para a preparação para o desenvolvimento que apenas para que possamos executar isso localmente para ilustrar o que ele vai fazer no servidor. Também não podemos esquecer de instalar as dependências que precisamos aqui para executar nosso servidor. Então vamos fazer isso agora. Salvar. Então precisamos servir o manipulador. Http está embutido, então não precisamos disso. E nó fetch. E estes serão salvos no pacote.json. Então BitBucket verá o mesmo package.json e instalá-los da mesma forma. E apenas como um teste, podemos executar o servidor agora mesmo. Ótimo, então temos os registros do console. E devemos ver as mesmas mensagens em nosso flack. - Sim. Este B32 e grok. Isso deve ser o mesmo que sim, exatamente, exatamente. Como nosso servidor requer esse arquivo de ambiente, também precisamos transferir isso. Então, podemos basicamente copiar isso. Só mais um set. Podemos defini-lo como um artefato. Se quisermos manter a mesma estrutura. E podemos fazer isso assim. E o mesmo. Mais uma vez, para o mestre. Este suporte é diferente. Então, é claro, quando avançamos para menos de cinco desenvolvimentos, nada acontecerá com a nossa compilação porque nós definimos apenas um pipeline para a filial de teste e mestre. Então vamos fundir isso agora e ver o que acontece. Vamos mudar para encenação e fundir-nos, desenvolver e empurrar isso. Portanto, nosso processo de construção funcionou até agora. A etapa de instalação e compilação leva cerca de três minutos. Mas isso vai ficar um pouco mais rápido. Como você pode ver, que Bitbucket está montando um novo dinheiro para nó como especificado. Mas aqui o comando scp para módulos Node está sendo executado por alguns minutos e isso é muito longo. Então, na próxima lição, vamos aprender como podemos acelerar a cópia todos esses arquivos no processo de set usando um tarball. 12. Como utilizar bolas para transferir os módulos de node Faster: Então o que podemos fazer para melhorar a velocidade do SEP é criar uma bola de alcatrão antes de transferi-la. Então eu vou parar este oleoduto. E vamos voltar para o nosso arquivo do oleoduto. Vou me certificar de que estamos na filial correta. E vamos fazer aqui é após o comando build, criar um tarball o mesmo nome de módulos Node. E os artefatos. Agora não precisamos de módulos Node, mas sim da bola de alcatrão que é criada. E também vamos renomear isso. Em vez de uma pasta. Só precisamos acertar esse diretório com esse arquivo. E faremos o mesmo para o ramo mestre. Então, para estar completo, temos que adicionar um passo adicional para descompactar a bola de alcatrão no lado do servidor. E nós estamos novamente, você vai usar um comando SSH para ser capaz de executar comandos no servidor. Vamos copiar isso para o mestre. Só tem que mudar o nome da pasta. Então isso deve acelerar muito o processo de construção e também será capaz de ver o quanto esse processo de cache salva também. Assim, podemos ver com este novo processo de construção com o tarball, primeiro lugar, ele termina o mais importante. Mas o tarball dos módulos do nó é implantado muito, muito mais rápido. Então, foi uma quantidade indeterminada de tempo. Eu não sei. Esperei uns quatro ou cinco minutos e depois parei, mas agora são só dez segundos. Além disso, vemos que o processo de cache interno de buckets de bits reduz esse tempo de instalação inicial. E o nó ImageDownloader, que foi cerca de três minutos a apenas um minuto. Então isso também é três vezes mais rápido. Agora, basicamente, fique essa quantidade de tempo. Pode ser um pouco mais longo se você adicionar alguns pacotes ao nó. E então também seria o tempo muito longo se você alterou ou atualizou sua imagem do nó do que teria que reformular a nova imagem. Mas, caso contrário, isso está bom. O que é saltar para o servidor para ter certeza de que tudo parece bem. Ótimo, então temos tudo aqui. Poderíamos adicionar um passo adicional para remover a bola de alcatrão que foi transferida. Mas vou deixar isso para vocês adicionarem. 13. Estabelecer para sempre o modo no servidor: Assim como no exemplo de site estático, criamos uma implantação contínua bem-sucedida, mas ainda não estamos servindo nada. Então, para ter certeza que implantamos todos os arquivos que precisamos, uma boa primeira verificação é simplesmente executar o índice de nó j s aqui no servidor. E esperamos obter esses logs para console e também vê-los em folga com as variáveis de teste. Como estamos na pasta de teste, é aí que nosso pipeline de teste implanta dois. E nós obtemos esses logs de console, bem como os logs de folga idênticos. E podemos até verificar aqui para garantir que as variáveis estejam corretas. E sim, ele diz Olá myTitle site de teste de preparação. Então parece ótimo. Então, é claro, não podemos vir aqui manualmente e emitir o nó index.js cada vez. E vimos a partir do site estático, mesmo que fosse um bom exemplo de como usar um comando SSH. Também foi um ideal para iniciar sempre o servidor dessa forma. E a maneira de fazer isso seria com sempre assistir índice JS. Mas o problema está aqui. Para sempre estaria assistindo muitos arquivos. Porque temos os módulos de nó aqui. Realmente tudo o que queremos ver é fonte e construir. Então, há um passo extra que precisamos fazer. E isso é criar um arquivo para sempre ignorar, que é exatamente como o arquivo gitignore. E então aqui queremos ignorar módulos de nó. E é claro que precisamos adicionar isso ao nosso oleoduto. E, na verdade, no script de construção só precisamos defini-lo como um artefato. E então podemos usar o SEP. Ótima. Tinha o mesmo com o mestre. Novamente, certificando-se de que essa é a pasta correta. E adicionando-o como um artefato. Tudo bem, então implantar nosso arquivo para sempre ignorar funcionou corretamente. E agora podemos começar para sempre sem que ele tenha quaisquer problemas, já que ignoramos a pasta de módulos de nó grande. Então, o comando é para sempre traço W, Iniciar index.js. E, claro, isso começa em segundo plano, mas ainda recebemos mensagens. Este é o nosso site de encenação ao vivo. E apenas para simular uma mudança, podemos simplesmente tocar em um novo arquivo. Vamos chamar de novo arquivo, TXT. E assim que eu faço isso, para sempre, percebe que a mudança e o site reinicia. Então, isso é ótimo. Sempre que arquivos SCP aqui para o servidor, para sempre vai reiniciar e iria refletir essas alterações no site. 14. A grande vantagem de de testes em oleodutos em estabelecendo e mesclando com mestro!: Então agora é hora de todo o nosso trabalho duro neste processo de construção valer a pena. E esse é o cenário em que você deseja mesclar para mestre. Então você pode pensar em todo o trabalho e mudanças que fizemos aqui na encenação. Meia dúzia de testes solares. E temos nos certificado de que tudo funciona e agora estamos bastante satisfeitos com a forma como o site está funcionando. Porque nós temos seguido em ambos os ramos de preparação e mestre com os mesmos passos exatos. Exceto para nossas pastas e ambientes personalizados. Esperamos que o processo de construção também funcione exatamente da mesma forma. Portanto, tudo o que precisamos fazer para migrar as alterações aprovadas e concluídas do teste é mesclar o teste para mestre e enviá-lo para o nosso controle remoto. E então BitBucket fará o resto por nós. Então, vamos tentar. Então aqui agora no servidor, não na pasta de teste, mas na pasta mestre. E parece que nosso script de construção funcionou exatamente como deveria. E podemos até realizar RNs. E nós deveríamos estar vendo o mestre exatamente as variáveis mestre. E como testes iniciais, assim como fizemos com o teste, podemos executar o nó index.js. Ótima. As mensagens de sinalização estão funcionando. console registra a porta correta e pega. E agora posso passar o mesmo comando que fizemos na encenação. Ótima. E para obter essa pré-visualização ao vivo, temos o site mestre e a preparação mais recente está aqui. Este é o local de preparação. Ótima. Então, temos dois aplicativos Web lado a lado. Eles estão expostos com n grok. O teste está sendo executado na porta 5.002 em nosso servidor e a ramificação mestre está sendo executada em 5.003. 15. BÔNUS: configuração de proxy NGINX e reaja variável de URL NGINX: Então, na última lição, construímos uma implantação contínua e integração contínua para dois ramos ao lado do outro, um ramo de preparação e um ramo mestre. E para essa tarefa, nós ainda estávamos usando e grok como uma ferramenta simples para proxy rapidamente o site e obtê-lo em um URL público na Internet. Mas como eu mencionei alguns cursos atrás, eu mostraria como eu faço isso usando uma ferramenta como motor X. E então eu já tenho meu arquivo de configuração de engenheiros aberto aqui para Chris através DOT IN, que é o meu blog. Então a raiz é o meu blog aqui. Mas se você acertar esses subdomínios, você obtém o que realmente está em segundo plano, um aplicativo de nó totalmente diferente. E eu também tenho meu portfólio, que é mais um aplicativo. Assim, podemos fazer o mesmo para os dois aplicativos que acabamos de criar. E eu vou colocá-los basicamente como o mesmo caminho que temos usado. Então nós temos este teste e nós proxy passar 25.002. E também temos o mestre. E isso é na porta 5.003. Nós apenas formatamos esse pequeno erro de digitação aqui. E podemos reiniciar e genética. Há um pequeno passo que esqueci de configurar quando se trata de Create React app. E podemos ver quando executamos a construção do NPM, eles dão um tipo de aviso. O projeto foi construído assumindo que ele está hospedado na raiz. Você pode controlar isso com o campo homepage em seu package.json. E, claro, com a nossa nova configuração de engenheiros, estamos na pasta de teste Type Script e compartilhamento de habilidades pasta mestre Type Script, não na raiz. E também não queremos definir uma página inicial estática no package.json porque estamos usando isso para ramificação do sistema localmente no repositório GitHub app Create React. Consegui encontrar uma maneira de definir esta variável de ambiente de URL pública, que é perfeita para o nosso caso de uso. Então, podemos adicionar isso pouco antes do comando run build. Vamos definir a variável de ambiente. E então nossa configuração deve funcionar bem com nosso motor X proxy. Então, estamos apenas usando a sintaxe bash padrão, exportar URL pública. E isso é HTTPS é enraizado IN habilidade compartilhamento tipo script preparação. Isso é para o ramo de encenação ou o ramo mestre. Mestre. Mas, claro, então, isso significa que devemos remover este código n grok. Então nós podemos realmente apenas remover a função completamente. E sabemos que a URL estará disponível em froude, AT IN barra, Compartilhamento de habilidades, tipo, script, teste e mestre. Então, vamos apenas empurrar este código através da cadeia típica começando em dev Ben para encenação, em seguida, para mestre, ainda vai receber nossa mensagem frouxa bem aqui. E deve ficar bem. Então vamos empurrar isto e ver como vai correr. Então, se investigarmos o processo de construção mais recente, vamos para a etapa de construção. Podemos ver no comando run build que Create React app entende o que estamos fazendo aqui. E eles dizem que é assumido que está hospedado aqui na URL que fornecemos. E em termos de configuração do servidor, ele funciona perfeitamente. E podemos ver que a variável de ambiente para o título do site também é preenchida dinamicamente e esperamos o mesmo para o site de preparação. Sim, perfeito. Então é assim que você serve para criar aplicativos React em ramificações separadas via motor X, proxies. 16. BÔNUS: usando o Docker como alternativa para um servidor remoto: Escrevi na descrição do curso que, se você não tiver nenhum tipo de servidor Linux remoto ou baseado em nuvem, seria capaz de usar uma instância local do Docker Linux como substituto. Então, esta lição descreve e mostra como você pode configurar isso. Então, depois de instalar o Docker em seu sistema, você pode usar este arquivo Docker para criar uma instância do Ubuntu com todos os requisitos necessários. Então eu vou, eu vou postar isso nas notas da lição. Ele inclui coisas como curl, get, e instala a versão do nó que precisamos para este curso. Então, uma vez que você obtém este arquivo, você pode construí-lo. E você vai notar que eu já estou diretamente nesta pasta ou este arquivo Docker está. Então podemos construí-lo com este comando. E agora podemos rodar essa imagem com o Doutor executar interativo. E vamos ligá-lo a um porto. Então eu escolhi o 777 arbitrariamente porque é mais fácil de lembrar e eu não acho que ele deve entrar em conflito com quaisquer outras portas. E precisamos vincular isso a 22 no lado mais escuro, que é a porta padrão para SSH. E referenciamos nosso ID de imagem copiado. E nós entramos. Então, agora que estamos em nossa instância do Ubuntu, devemos garantir que os serviços SSH para cima. Então vamos emitir esse comando. Parece OK. E também devemos definir uma senha para este usuário. E isso é o que o passado comando WD. Então, se você está planejando usar isso para todo o curso, e você vai acessá-lo de público, por exemplo, de Bitbucket, de uma fonte externa, você deve definir uma senha muito forte aqui, já que eu só estou usando para um exemplo agora, vou definir uma senha bastante simples. E então você tem que confirmar. E as senhas foram atualizadas com sucesso. Portanto, é importante manter esta instância de terminal em execução. Esta é a nossa imagem Ubuntu que está em execução e Docker. Então vamos abrir um terminal separado. E podemos verificar se podemos fazer login localmente pelo SSH. Então, esse será o usuário root. Apenas que nosso próprio localhost, um a sete, 0.0.0, 0.1. E a porta arbitrária que especificamos, que é 7777. E forneça a senha definida com o comando password. E parece que estamos dentro. Agora, para ter um acesso de fonte externa, essa imagem como pipelines de bitbucket terá que abrir porta 777 para aceitar conexões SSH do mundo. Então, para fazer isso, primeiro precisamos conhecer esta máquina local. No meu caso, meu laptop, o que é endereço IP está na minha própria rede Wi-Fi. E assim podemos sair do SSH aqui. E para conseguir isso, você pode emitir IF Config e grep para ion em 19 dois e isso deve ser capaz de encontrar seu endereço. Se nada aparecer aqui, você pode ter que emitir o IF Config completo e olhar toda a listagem lá. Mas vemos que o endereço local deste laptop na minha rede é este. Então podemos copiar isso agora. E vamos criar uma regra de encaminhamento de porta em nosso roteador. Então, normalmente você pode acessar a GUI do seu roteador Wi-Fi apenas colocando em qualquer navegador, 19 2.168.1. E talvez seja necessário examinar as especificações técnicas do seu roteador para obter as credenciais para fazer login. Mas uma vez que você está dentro, quase todos os roteadores têm esse layout geral. E o que você quer encontrar é em avançado ou encaminhamento direto. Depende do fabricante. Normalmente, você tem que ir para uma guia avançada e, em seguida, encontrar o encaminhamento. E você pode definir essas regras. Então vamos criar uma regra de encaminhamento IP v4. E então ignore o somador de regras conhecido. E nós vamos descer aqui. Então sabemos quais são os nossos endereços IP locais, nós apenas copiamos. E queremos que o início e o fim locais sejam a porta que especificamos. O IP externo. No meu caso, para este roteador, você pode deixá-lo como este 0, este todos os zeros. Alguns roteadores, você precisa deixá-lo vazio. Novamente, você precisa ler na documentação do seu roteador qual é a regra. Mas apenas para lembrá-lo para o nosso próprio eixo, vamos definir a porta externa para todos os setes também. E você também pode fornecer uma descrição. Vou dizer SSH ao Docker e queremos ativá-lo. E clique em Aplicar. Ótimo, vemos nossa entrada aqui. Então isso parece bom para ir agora para ser capaz acessar isso de um site externo ou do público, você precisa do seu endereço IP público, não este local, mas sim aquele que seu provedor de serviços de internet vê ou que Você é. Roteador mostra a Internet. A maneira mais fácil de fazer isso é simplesmente entrar no Google e pesquisar quais endereços IP. Então, apenas para um exemplo simples, digamos que seu endereço IP público seja 1.5.2, 1.5.2, 1.5.2, 1.5.2, 1.5.2. A maneira como você pode testar se o encaminhamento de porta funcionou é quase o mesmo comando que emitimos para o teste local. Então é raiz SSH. E se estamos assumindo que esse é o seu endereço IP público, ainda porta 7777. Isso deve funcionar. Então, o que realmente está acontecendo em segundo plano é que você está acertando seu roteador neste endereço. O roteador procura a regra. Diz, ah, está solicitando no 7777 e depois encaminhando para a sua máquina local. No meu caso, esta máquina e o Docker estão então encaminhando a porta 22 77772 conforme configuramos em nossa imagem. E você poderá chegar ao seu SSH, ou poderá acessar a imagem através do SSH. Então, se este comando está funcionando e você pode acessar sua imagem de um lugar público ou externo na internet. Você está pronto e pode usar a imagem do Docker para este curso. É importante, sempre que você estiver executando qualquer coisa ou esperando bitbucket, por exemplo, para fazer login, que isso esteja sempre em execução. E quando você terminar com esta imagem, você pode simplesmente terminar sua execução com o comando exit e sair do mesmo terminal onde você começou, ele irá automaticamente e sua execução. E podemos verificar novamente isso emitindo ps docker. E vemos que não há imagens em execução. Tenha em mente que, se você estiver indo para usar este método Docker, você também terá que atualizar o valor do servidor em suas variáveis de repositório. Assim, o usuário pode permanecer como root como dissemos no curso. Mas o servidor terá que ser aquele IP público que você procurou, por exemplo, no Google. E então suas regras de encaminhamento de porta devem fazer todo o resto do trabalho para você. E você deve ser capaz de acessar sua instância local do Linux no Docker, assim como faria com qualquer outro tipo de caixa Linux remota. Você também terá que refazer as etapas do SSH, o que fizemos na lição quatro com a chave pública e privada. Para que sua instância local do Ubuntu confie no acesso SSH a partir do Bitbucket. Então, nesta lição bônus, aprendemos como podemos configurar rapidamente uma instância do Ubuntu executando localmente usando o Docker. Abrimos um porto de nossa escolha. Nesse caso, neste exemplo, era 7777 para a Internet criando uma regra de encaminhamento de porta em nosso roteador. Encaminhando a porta externa 777 para a porta local 777 em nossa máquina local.