Muito bom, obrigado pelo vídeo. Já utilizava o CI/CD do GitLab que também é muito bom, mas acabei migrando para GitHub pelo tempo de pipeline gratuito ser maior.
Muito bom vídeo, sou dev mas sou leigo nessa área de DevOps, nunca construi ou gerenciei uma pipeline mesmo utilizando todos os dias, e agora preciso fazer manutenção nessas tecnologias tendo que aprender do zero.
Eu tenho achado o GitHub Actions uma maravilha. Na empresa que trabalho estava avaliando jenkis por precisar de alguns recursos de lá, mas aí veio a opção de rodar as Actions self hosted. O procedimento é tão simples, mas representou uma evolução tão grande pra gente que eu até quero escrever sobre heheh. Vou fazer propaganda do seu canal pra quem quiser aprender 😁
Tenho projetos modulares que ficam em repos diferentes, hoje ao gerar o build e esse cara depende de um desses módulos, eles também são buildados, há como fazer isso no actions?
Show Julio, muito top sua aula. Uma dúvida, como faço para um Child rodar sempre que houver uma alteração na Master. Assim que rodar o pacote, a child que aponta para essa master, identificar que houve alteração e execute? to apanhando aqui pra fazer funcionar isto. abs
@@JulioArruda Obrigado pelo reply. Eu tenho o Banche Master no meu repositório e várias Workflows apontando pra este banche. Se eu altero algo na Master e rodo ela pra gerar um novo pacote, eu gostaria que todas as Worflows identificasse que a mudança foi completada e rodasse automaticamente. Eu setei no yml de um workflow o seguinte comando abaixo para que identifique a Master rodou 100% e ae ela rode, ta certo assim?: name: CI/CD for child project on: check_run: types: [completed] branches: - master
@@JulioArruda muito obrigado Júlio, sua dica vale ouro. Vou validar aqui nos meus projetos. Parabéns pelo conteúdo e ajuda dada a nós. Forte abraço e sucesso!
Julio você tem algum exemplo para me explicar em quais casos eu poderia rejeitar o deploy de homologação, eu meio que não entendi muito essa parte, eu rejeitaria se o deploy no ambiente em desenvolvimento estivesse com algum erro ou bug?
É essa a ideia mesmo… se o time de desenvolvimento fez alguns testes em Dev, e identificaram que essa versão está ruim e ainda precisa de correção, não tem porque mandar pra homologação, e nesse caso você rejeitaria o deploy Ou se fizeram o deploy pra testar ago que ainda não está pronto, também não faz sentido seguir
@@JulioArruda O ambiente de homologação seria meio que uma copia do ambiente de produção? tipo depois que eu aprovasse para homologação é só aprovar para produção ou precisa verificar uma segunda vez para ver se tem bugs ai se não houver bugs aprovar para produção?
Então.. todos os ambientes deveriam ser estruturalmente iguais, com diferenças somente nas massas de dados, e quantidade de recursos. E também, cada ambiente tem seu uso Desenvolvimento seria usado pelo time de Dev Homologação pelo time de testes E produção pelo usuário final Oque vale lembrar aqui, é que você não tem que se prender a esses 3 ambientes apenas, tem empresas que tem vários ambientes cada um com uma necessidade diferente
Pena que o recurso Enviroments um recurso tão basico só está disponível para repos públicos, se vc tem um projeto particular só comprando o empresarial enterprise para liberar essa opção.
IRADO esse vídeo... Comecei a me aventurar nesse mundo das Actions do Github e confesso que tem sido uma surra atrás da outra... Mas o problema na pecinha que fica entre a cadeira e o teclado, rs! Mas uma coisa que acabei de notar, a opção de Environments, só fica disponível em projetos públicos, acabei de testar em um privado e ela não aparece... Uma outra dúvida que ainda tenho, é por exemplo. Você colocou todos os passos, no mesmo arquivo, mas supondo que eu queira separar eles, o "needs: deploy-dev" por exemplo, funcionaria? Digo isso, partindo que eu esteja em outro arquivo, mas que o processo, seja dependente desse fluxo...
Sim, quanto aos Environments por hora só pra repo público.. (lançamento em beta ainda). Quanto a parte de arquivos separados, nessa eu posso estar errado, mas até onde eu sei, até o momento precisa estar tudo junto
Muito bom, obrigado pelo vídeo. Já utilizava o CI/CD do GitLab que também é muito bom, mas acabei migrando para GitHub pelo tempo de pipeline gratuito ser maior.
Brother, curti o video e a nova feature.
Cada vez mais veremos pipelines mais completos. Show de bola
Video muito bom... Todo bem claro e preciso... ta de parabens
Bacana Julio, mais um adicional as actions que ja eram interessantes. Até a live de sábado.
Obrigado por compartilhar.
Muito top essa novidade! Não conhecia o canal e estou inscrito.
Parabéns pela explicação e até sábadou...
Show.. 👊
Poxa.. muito bom cara... vou testar com certeza! Parabéns pelo vídeo Julio!
Muito bom vídeo, sou dev mas sou leigo nessa área de DevOps, nunca construi ou gerenciei uma pipeline mesmo utilizando todos os dias, e agora preciso fazer manutenção nessas tecnologias tendo que aprender do zero.
Muito obrigado pelo compartilhamento de conhecimento !!!
Eu tenho achado o GitHub Actions uma maravilha. Na empresa que trabalho estava avaliando jenkis por precisar de alguns recursos de lá, mas aí veio a opção de rodar as Actions self hosted. O procedimento é tão simples, mas representou uma evolução tão grande pra gente que eu até quero escrever sobre heheh. Vou fazer propaganda do seu canal pra quem quiser aprender 😁
🎉🎉
Like por ser fâ de Doctor Who haha, parabéns pelo conteúdo
Tenho projetos modulares que ficam em repos diferentes, hoje ao gerar o build e esse cara depende de um desses módulos, eles também são buildados, há como fazer isso no actions?
Show Julio, muito top sua aula. Uma dúvida, como faço para um Child rodar sempre que houver uma alteração na Master. Assim que rodar o pacote, a child que aponta para essa master, identificar que houve alteração e execute? to apanhando aqui pra fazer funcionar isto. abs
Oque vc quer dizer com Child especificamente?
Porque pra um pipe rodar sempre que tiver uma alteração na Main, basta ter trigger on: push: main
@@JulioArruda Obrigado pelo reply. Eu tenho o Banche Master no meu repositório e várias Workflows apontando pra este banche. Se eu altero algo na Master e rodo ela pra gerar um novo pacote, eu gostaria que todas as Worflows identificasse que a mudança foi completada e rodasse automaticamente. Eu setei no yml de um workflow o seguinte comando abaixo para que identifique a Master rodou 100% e ae ela rode, ta certo assim?:
name: CI/CD for child project
on:
check_run:
types: [completed]
branches:
- master
Opa, acho que respondi sua pergunta nesse vídeo de hoje. :) th-cam.com/video/VwP2Q8FLwEM/w-d-xo.html
@@JulioArruda muito obrigado Júlio, sua dica vale ouro. Vou validar aqui nos meus projetos. Parabéns pelo conteúdo e ajuda dada a nós. Forte abraço e sucesso!
Eu consigo configurar o Github Actions pra lançar o meu deploy dentro de uma vps windows com IIS?
Sim, conseguiria
@@JulioArruda opa mestre, sabe onde poderia encontrar um tutorial a respeito? Obrigado pela informação, seu conteúdo é top demais
Muito legal essa feature. Mas como seria num projeto AWS-Lambdas?
Boa.. vou ver se trago algo sobre
Cara, primeiramente parabéns pela pergunta!
Super apoio e reforço a solicitação, abraço a todos!
@@JulioArruda Obrigado.
Julio você tem algum exemplo para me explicar em quais casos eu poderia rejeitar o deploy de homologação, eu meio que não entendi muito essa parte, eu rejeitaria se o deploy no ambiente em desenvolvimento estivesse com algum erro ou bug?
É essa a ideia mesmo… se o time de desenvolvimento fez alguns testes em Dev, e identificaram que essa versão está ruim e ainda precisa de correção, não tem porque mandar pra homologação, e nesse caso você rejeitaria o deploy
Ou se fizeram o deploy pra testar ago que ainda não está pronto, também não faz sentido seguir
@@JulioArruda O ambiente de homologação seria meio que uma copia do ambiente de produção? tipo depois que eu aprovasse para homologação é só aprovar para produção ou precisa verificar uma segunda vez para ver se tem bugs ai se não houver bugs aprovar para produção?
Então.. todos os ambientes deveriam ser estruturalmente iguais, com diferenças somente nas massas de dados, e quantidade de recursos.
E também, cada ambiente tem seu uso
Desenvolvimento seria usado pelo time de Dev
Homologação pelo time de testes
E produção pelo usuário final
Oque vale lembrar aqui, é que você não tem que se prender a esses 3 ambientes apenas, tem empresas que tem vários ambientes cada um com uma necessidade diferente
@@JulioArruda Obrigado pela explicação, sou novo nesse mundo de DevOps eu achava que CI/CD era coisa e outro mundo kkkk
Posso saber qual que é esse braço de microfone? Eu ja comprei o mic para quero um braço obrigado!
É aquele mais baratinho que tem na Amazon
@@JulioArruda Obrigado!
Pena que o recurso Enviroments um recurso tão basico só está disponível para repos públicos, se vc tem um projeto particular só comprando o empresarial enterprise para liberar essa opção.
IRADO esse vídeo... Comecei a me aventurar nesse mundo das Actions do Github e confesso que tem sido uma surra atrás da outra... Mas o problema na pecinha que fica entre a cadeira e o teclado, rs! Mas uma coisa que acabei de notar, a opção de Environments, só fica disponível em projetos públicos, acabei de testar em um privado e ela não aparece... Uma outra dúvida que ainda tenho, é por exemplo. Você colocou todos os passos, no mesmo arquivo, mas supondo que eu queira separar eles, o "needs: deploy-dev" por exemplo, funcionaria? Digo isso, partindo que eu esteja em outro arquivo, mas que o processo, seja dependente desse fluxo...
Sim, quanto aos Environments por hora só pra repo público.. (lançamento em beta ainda).
Quanto a parte de arquivos separados, nessa eu posso estar errado, mas até onde eu sei, até o momento precisa estar tudo junto
Eu testei separado pelo menos na época não funcionava. Parece que existe a idéia de permitir isso, vamos aguardar.
No meu o link não deu certo por que sera ?
Não sei.. recebeu algum erro?
Que deu deslike não tem mãe! Ótimo vídeo!