Implantar um projeto usando o Git push


412

É possível implantar um site usando git push? Eu tenho um palpite de que tem algo a ver com o uso de ganchos git para executar um git reset --hardno lado do servidor, mas como eu iria conseguir isso?


2
Suponho que isso se aplicaria apenas em situações em que há apenas um servidor de produção, certo?
Rijk

6
@Rijk Bem, você pode enviar para vários servidores simultaneamente com o Git, mas assim que chegar a esse nível, poderá querer uma solução real, não um hack como esse.
precisa

Tive sucesso usando o capistrano com meus projetos, que embora tenham sido originalmente projetados para a implantação de aplicativos Ruby on Rails, funcionam bem com PHP e outros projetos.

Traduziu as respostas para o russo em ru.so: ru.stackoverflow.com/questions/428483/…
Nick Volynkin

Respostas:


287

Eu encontrei este script em este site e parece funcionar muito bem.

  1. Copie o diretório .git para o servidor da web
  2. Na sua cópia local, modifique seu arquivo .git / config e adicione seu servidor web como um controle remoto:

    [remote "production"]
        url = username@webserver:/path/to/htdocs/.git
    
  3. No servidor, substitua .git / hooks / pós-atualização por este arquivo (na resposta abaixo)

  4. Adicione acesso de execução ao arquivo (novamente, no servidor):

    chmod +x .git/hooks/post-update
    
  5. Agora, basta enviar localmente para o servidor da Web e ele deve atualizar automaticamente a cópia de trabalho:

    git push production
    

128
Verifique se você possui uma política .htaccess que protege o diretório .git de ser lido. Alguém que gosta de mergulhar com URL pode ter um dia de campo com todo o código-fonte, se estiver acessível.
Jeff Ferland

39
Como alternativa, apenas torne o diretório público um subdiretório do repositório git. Depois, você pode ter arquivos particulares, para ter certeza de que não serão publicados.
tlrobinson

3
esse link está morto. existe outro link para o arquivo pós-atualização?
Robert Hurst

6
Talvez esteja faltando alguma coisa, mas você não gostaria que seu servidor de produção puxasse de uma ramificação de produção de repositórios mestre do git. Eu acho que o OP tem apenas um servidor? Normalmente, faço o meu servidor de integração contínua fazer a implantação do meu site (executando alguns testes antes da implantação).
Adam Gent

4
Seguindo essas etapas em um repositório que já possui uma sequência de confirmações; no início, você não pode enviar porque o ramo principal já está com check-out. Então, se você efetuar o check-out de uma ramificação alternativa no controle remoto, apenas os arquivos diferentes serão transferidos para o diretório de trabalho. Eu esperava que o gancho para fazer uma --hard redefinido para mim
barrymac

80

Usando o arquivo pós-atualização abaixo:

  1. Copie o diretório .git para o servidor da web
  2. Na sua cópia local, modifique seu arquivo .git / config e adicione seu servidor web como um controle remoto:

    [remote "production"]
        url = username@webserver:/path/to/htdocs/.git
    
  3. No servidor, substitua .git / hooks / post-update pelo arquivo abaixo

  4. Adicione acesso de execução ao arquivo (novamente, no servidor):

    chmod +x .git/hooks/post-update
    
  5. Agora, basta enviar localmente para o servidor da Web e ele deve atualizar automaticamente a cópia de trabalho:

    git push production
    
#!/bin/sh
#
# This hook does two things:
#
#  1. update the "info" files that allow the list of references to be
#     queries over dumb transports such as http
#
#  2. if this repository looks like it is a non-bare repository, and
#     the checked-out branch is pushed to, then update the working copy.
#     This makes "push" function somewhat similarly to darcs and bzr.
#
# To enable this hook, make this file executable by "chmod +x post-update". 
git-update-server-info 
is_bare=$(git-config --get --bool core.bare) 
if [ -z "$is_bare" ]
then
      # for compatibility's sake, guess
      git_dir_full=$(cd $GIT_DIR; pwd)
      case $git_dir_full in */.git) is_bare=false;; *) is_bare=true;; esac
fi 
update_wc() {
      ref=$1
      echo "Push to checked out branch $ref" >&2
      if [ ! -f $GIT_DIR/logs/HEAD ]
      then
             echo "E:push to non-bare repository requires a HEAD reflog" >&2
             exit 1
      fi
      if (cd $GIT_WORK_TREE; git-diff-files -q --exit-code >/dev/null)
      then
             wc_dirty=0
      else
             echo "W:unstaged changes found in working copy" >&2
             wc_dirty=1
             desc="working copy"
      fi
      if git diff-index --cached HEAD@{1} >/dev/null
      then
             index_dirty=0
      else
             echo "W:uncommitted, staged changes found" >&2
             index_dirty=1
             if [ -n "$desc" ]
             then
                   desc="$desc and index"
             else
                   desc="index"
             fi
      fi
      if [ "$wc_dirty" -ne 0 -o "$index_dirty" -ne 0 ]
      then
             new=$(git rev-parse HEAD)
             echo "W:stashing dirty $desc - see git-stash(1)" >&2
             ( trap 'echo trapped $$; git symbolic-ref HEAD "'"$ref"'"' 2 3 13 15 ERR EXIT
             git-update-ref --no-deref HEAD HEAD@{1}
             cd $GIT_WORK_TREE
             git stash save "dirty $desc before update to $new";
             git-symbolic-ref HEAD "$ref"
             )
      fi 
      # eye candy - show the WC updates :)
      echo "Updating working copy" >&2
      (cd $GIT_WORK_TREE
      git-diff-index -R --name-status HEAD >&2
      git-reset --hard HEAD)
} 
if [ "$is_bare" = "false" ]
then
      active_branch=`git-symbolic-ref HEAD`
      export GIT_DIR=$(cd $GIT_DIR; pwd)
      GIT_WORK_TREE=${GIT_WORK_TREE-..}
      for ref
      do
             if [ "$ref" = "$active_branch" ]
             then
                   update_wc $ref
             fi
      done
fi

5
Nossa ... basta escrever esse script em uma linguagem que você usa para o desenvolvimento, seja php, python, groovy ou qualquer outra coisa! Eu nunca entendi esse amor por scripts de shell que têm (subjetivamente) sintaxe bastante estranha e tão poucos recursos funcionais.
dVaffection

4
@dVaffection em qualquer caso, você irá escrever comandos shell se estiver usando o git. então, em vez de escrever um script em outro idioma e constantemente fazer malabarismos entre esse idioma e o shell. escrever tudo com casca parece lógico, você não acha?
Abderrahmane TAHRI JOUTI 14/01

Eu tive que executar 'git config receive.denyCurrentBranch updateInstead' no servidor também, para que ele aceitasse o envio. Eu acho que é porque o ramo foi retirado?
stackPusher

60

Depois de muitas partidas e becos sem saída, finalmente consegui implantar o código do site com apenas "git push remote ", graças a este artigo .

O script pós-atualização do autor tem apenas uma linha e sua solução não requer a configuração .htaccess para ocultar o repositório Git, como alguns outros.

Alguns obstáculos se você estiver implantando isso em uma instância do Amazon EC2;

1) Se você usar o sudo para criar o repositório de destino vazio, precisará alterar o proprietário do repositório para ec2-user ou o envio falhará. (Tente "chown ec2-user: ec2-user repo .")

2) O envio falhará se você não pré-configurar o local do seu .pem da amazon-private-key , em / etc / ssh / ssh_config como um parâmetro IdentityFile ou em ~ / .ssh / config usando o "[ Host] - Nome do host - IdentityFile - Usuário "layout descrito aqui ...

... NO ENTANTO, se o Host estiver configurado em ~ / .ssh / config e diferente de HostName, o push do Git falhará. (Isso provavelmente é um bug do Git)


Segui as etapas do artigo que você mencionou e tudo funcionou como um encanto. Só me pergunto se existem algumas desvantagens em relação à segurança ou estabilidade. Algum conselho sobre isso?
Xlttj

xl-t: Supondo que você esteja usando o Git sobre o SSH, eu diria que o perigo está em cometer um erro com o Git. Você pode perguntar ao autor do artigo; ele termina com "Perguntas e sugestões são bem-vindas". Minha estratégia de replicação atual (com morte cerebral) é usar o Transmit by Panic Software.
quer

1
O artigo vinculado tem um requisito importante ao usar ganchos. Os ganchos falharão se o .git estiver no mesmo esquema de nomes que o diretório ativo. ie / foo / bar (diretório de trabalho) e /foo/bar.git (repositório barebone git). Portanto, certifique-se de renomear / foo / bar para outra coisa, como /foo/bar.live ou / foo / blah Bem, caso esteja se perguntando, a mensagem de erro exata que você receberia se seu diretório de trabalho tivesse o mesmo nome que o repositório barebone é "remoto: fatal: não foi possível retornar ao cwd original: não existe esse arquivo ou diretório"
Antony

1
Não entendo por que você precisaria de um gancho pós-implantação para executar. Enviar o código por push para um repositório remoto significa que o repositório remoto está atualizado. o que estou perdendo?
Charlie Schliesser

1
@CharlieS, o que você está perdendo é que o git não permite enviar uma ramificação para um repositório que possui essa ramificação em check-out. Nesse caso, a resposta (IMHO muito boa) é ter dois repositórios: um repositório vazio para o qual você envia e um segundo repositório cujo diretório de trabalho é atualizado via gancho quando o repositório vazio é enviado.
Ben Hughes

21

não instale o git em um servidor ou copie a pasta .git lá. para atualizar um servidor a partir de um clone git, você pode usar o seguinte comando:

git ls-files -z | rsync --files-from - --copy-links -av0 . user@server.com:/var/www/project

pode ser necessário excluir arquivos que foram removidos do projeto.

isso copia todos os arquivos registrados. O rsync usa o ssh, que é instalado em um servidor de qualquer maneira.

quanto menos software você instalou em um servidor, mais seguro ele é e mais fácil é gerenciar sua configuração e documentá-la. também não há necessidade de manter um clone git completo no servidor. apenas torna mais complexo proteger tudo corretamente.


3
Uma ressalva: ele irá sincronizar novamente os arquivos que você possui no seu diretório de trabalho. Eu acho que pode ser evitado o uso de um script que esconde as alterações atuais, limpa tudo, implanta e depois reverte o esconderijo.
Mateusz.fiolka

Servidores são do sexo masculino?
23817 Ian Warburton

12

Em essência, tudo o que você precisa fazer é o seguinte:

server = $1
branch = $2
git push $server $branch
ssh <username>@$server "cd /path/to/www; git pull"

Eu tenho essas linhas no meu aplicativo como um executável chamado deploy.

então, quando eu quero fazer uma implantação, digito ./deploy myserver mybranch.


veja a minha resposta como resolver o problema se você precisa de uma chave ou nome de usuário privada diferente para ssh
Karussell

Esta solução é mais rápida do que a minha quando implantada em vários servidores! Basta pressionar o repositório principal e puxar em paralelo a ele. E se você não quiser ou não puder implantar suas chaves em todas as instâncias, use o agente de chaves! ssh -A ...
31412 Karussell

1
Seria mais fácil se você incluiu um guia sobre a configuração de chaves SSH que esta resposta depende de trabalho 'perfeitamente'
Hengjie

O uso de git pulldeve ser evitado para implantações automatizadas porque a parte de mesclagem pode exigir limpeza manual se houver algum conflito.
Quinn Comendant

9

A maneira como faço isso é ter um repositório Git vazio no meu servidor de implantação, onde envio as alterações. Depois, efetuo login no servidor de implantação, mudo para o diretório real de documentos do servidor web e faço um git pull. Não uso ganchos para tentar fazer isso automaticamente, isso parece mais problemas do que vale a pena.


Em caso de erro (s) no novo código, você redefine por confirmação ou por toda a solicitação? (Ou é apenas 1 possível?)
Rudie

1
@ Rudie: Se você precisar reverter as alterações no servidor de implantação, poderá usar git resetas alterações mais recentes (todas as confirmações, não apenas toda a solicitação). Se você precisar reverter algo específico que não seja o commit mais recente, poderá usá-lo, git revertmas provavelmente deve ser usado apenas em emergências ( git revertcria um novo commit que desfaz o efeito de algum commit anterior).
Greg Hewgill

Apenas por curiosidade: por que você acha que os ganchos seriam mais problemas do que vale a pena?
Rijk

@Rijk: Ao usar ganchos para isso, o diretório de documentos do servidor da Web real é alterado por um processo automático em segundo plano. O login permite que eu tenha mais controle sobre exatamente quando as alterações são aplicadas ao diretório docs. Além disso, é mais fácil corrigir quando as coisas dão errado. Ganchos podem ser mais apropriados se os committers não tiverem acesso suficiente para efetuar login no servidor da web.
Greg Hewgill 13/03/12

Portanto, sua pasta webapp real também é um repositório .git? E a pasta .git, é visível para o mundo exterior?
287 Fernando

9

git config --local receive.denyCurrentBranch updateInstead

Adicionado no Git 2.3, essa pode ser uma boa possibilidade: https://github.com/git/git/blob/v2.3.0/Documentation/config.txt#L2155

Você o define no repositório do servidor e também atualiza a árvore de trabalho, se estiver limpa.

Houve mais melhorias no 2.4 com o push-to-checkoutgancho e manuseio de galhos não nascidos .

Uso da amostra:

git init server
cd server
touch a
git add .
git commit -m 0
git config --local receive.denyCurrentBranch updateInstead

cd ..
git clone server local
cd local
touch b
git add .
git commit -m 1
git push origin master:master

cd ../server
ls

Resultado:

a
b

Isso tem as seguintes deficiências mencionadas no anúncio do GitHub :

  • Seu servidor conterá um diretório .git contendo todo o histórico do seu projeto. Você provavelmente quer ter certeza de que ele não pode ser exibido aos usuários!
  • Durante as implantações, será possível que os usuários encontrem momentaneamente o site em um estado inconsistente, com alguns arquivos na versão antiga e outros na nova versão, ou até arquivos meio gravados. Se esse é um problema para o seu projeto, o envio por push provavelmente não é para você.
  • Se o seu projeto precisar de uma etapa de "compilação", será necessário configurá-la explicitamente, talvez por meio de githooks.

Mas todos esses pontos estão fora do escopo do Git e devem ser resolvidos por código externo. Portanto, nesse sentido, isso, juntamente com os ganchos Git, são a solução definitiva.


Para configurá-lo, execute este comando: 'git config receive.denyCurrentBranch updateInstead' no terminal
stackPusher

5

Atualização: agora estou usando a solução Lloyd Moore com o agente principal ssh -A .... Empurrar para um repositório principal e depois retirá-lo em paralelo de todas as suas máquinas é um pouco mais rápido e requer menos configuração nessas máquinas.


Não está vendo esta solução aqui. basta pressionar via ssh se o git estiver instalado no servidor.

Você precisará da seguinte entrada no seu .git / config local

[remote "amazon"]
    url = amazon:/path/to/project.git
    fetch = +refs/heads/*:refs/remotes/amazon/*

Mas ei, o que é isso amazon:? No seu local ~ / .ssh / config, você precisará adicionar a seguinte entrada:

Host amazon
    Hostname <YOUR_IP>
    User <USER>
    IdentityFile ~/.ssh/amazon-private-key

agora você pode ligar

git push amazon master
ssh <USER>@<YOUR_IP> 'cd /path/to/project && git pull'

(BTW: /path/to/project.git é diferente do diretório de trabalho real / caminho / para / projeto)


5

Para cenário de implantação

Em nosso cenário, estamos armazenando o código no github / bitbucket e queremos implantar em servidores ativos. Nesse caso, a seguinte combinação funciona para nós (que é um remix das respostas altamente votadas aqui) :

  1. Copie seu .gitdiretório para o servidor da web
  2. Na sua cópia local git remote add live ssh://user@host:port/folder
  3. No controle remoto: git config receive.denyCurrentBranch ignore
  4. No controle remoto: nano .git/hooks/post-receivee adicione este conteúdo:

    #!/bin/sh GIT_WORK_TREE=/var/www/vhosts/example.org git checkout -f

  5. No controle remoto: chmod +x .git/hooks/post-receive

  6. Agora você pode ir lá com git push live

Notas

  • Esta solução funciona com versões mais antigas do git (testadas com 1.7 e 1.9)
  • Você precisa garantir o envio ao github / bitbucket primeiro, para ter um repo consistente ao vivo
  • Se sua .gitpasta estiver na raiz do documento, oculte-a do lado de fora adicionando a .htaccess( fonte ):

    RedirectMatch 404 /\..*$


4

Usamos o capistrano para gerenciar a implantação. Criamos o capistrano para implantar em um servidor intermediário e, em seguida, executamos um rsync com todo o nosso servidor.

cap deploy
cap deploy:start_rsync (when the staging is ok)

Com o capistrano, podemos facilitar a reversão em caso de erro

cap deploy:rollback
cap deploy:start_rsync

você integrou a implantação ao vivo via rsync no capistrano?
Martin Abraham


1

Parece que você deve ter duas cópias no seu servidor. Uma cópia simples, da qual você pode enviar / enviar, que enviaria suas alterações quando terminar e, em seguida, clonaria isso no diretório da web e configuraria um cronjob para atualizar o git pull do diretório da web todos os dias ou tão.


1

Você pode configurar um gancho git que, quando se diz que um commit é feito para dizer o ramo "stable", ele puxa as alterações e as aplica no site PHP. A grande desvantagem é que você não terá muito controle se algo der errado e isso adicionará tempo aos seus testes - mas você pode ter uma idéia de quanto trabalho será envolvido quando você mesclar, diga o seu ramo de tronco no ramo estável para saber quantos conflitos você pode encontrar. Será importante ficar de olho em todos os arquivos específicos do site (por exemplo, arquivos de configuração), a menos que você pretenda executar apenas o site.

Como alternativa, você já tentou fazer a alteração no site?

Para obter informações sobre git hooks, consulte a documentação do githooks .


1

Minha opinião sobre a solução dos cristãos .

git archive --prefix=deploy/  master | tar -x -C $TMPDIR | rsync $TMPDIR/deploy/ --copy-links -av username@server.com:/home/user/my_app && rm -rf $TMPDIR/deploy
  • Arquiva o ramo principal no alcatrão
  • Extrai o arquivo tar para o diretório deploy na pasta temp do sistema.
  • rsync muda para servidor
  • excluir diretório de implantação da pasta temp.

1

Estou usando a seguinte solução do toroid.org , que possui um script de gancho mais simples.

no servidor:

$ mkdir website.git && cd website.git
$ git init --bare
Initialized empty Git repository in /home/ams/website.git/

e instale o gancho no servidor:

$ mkdir /var/www/www.example.org
$ cat > hooks/post-receive
#!/bin/sh
GIT_WORK_TREE=/var/www/www.example.org git checkout -f
GIT_WORK_TREE=/var/www/www git clean -f -d # clean directory from removed files

$ chmod +x hooks/post-receive

no seu cliente:

$ mkdir website && cd website
$ git init
Initialized empty Git repository in /home/ams/website/.git/
$ echo 'Hello, world!' > index.html
$ git add index.html
$ git commit -q -m "The humble beginnings of my web site."

$ git remote add web ssh://server.example.org/home/ams/website.git
$ git push web +master:refs/heads/master

para publicar, basta digitar

$ git push web

Há uma descrição completa no site: http://toroid.org/ams/git-website-howto


dessa forma, não exclua os arquivos existentes no repositório.
RusAlex # 28/15

2
Por que ao git push web +master:refs/heads/masterinvés de apenas git push web master?
Matthieu Moy

1

Como resposta complementar, gostaria de oferecer uma alternativa. Estou usando o git-ftp e funciona bem.

https://github.com/git-ftp/git-ftp

Fácil de usar, apenas digite:

git ftp push

e o git fará o upload automático dos arquivos do projeto.

Saudações


0

Dado um ambiente em que você tem vários desenvolvedores acessando o mesmo repositório, as seguintes diretrizes podem ajudar.

Verifique se você possui um grupo unix ao qual todos os desenvolvedores pertencem e dê a propriedade do repositório .git a esse grupo.

  1. No .git / config do repositório do servidor, configure sharedrepository = true. (Isso diz ao git para permitir vários usuários, necessários para confirmações e implantação.

  2. defina o umask de cada usuário em seus arquivos bashrc para ser o mesmo - 002 é um bom começo


0

Acabei criando minha própria ferramenta rudimentar de implantação, que retiraria automaticamente novas atualizações do repositório - https://github.com/jesalg/SlimJim - Basicamente, ele escuta o github pós-recebimento-gancho e usa um proxy para acionar um script de atualização.


0

Eu uso duas soluções para gancho pós-recebimento:

SOLUÇÃO DE IMPLANTAÇÃO 1

#!/bin/bash 
#  /git-repo/hooks/post-receive - file content on server (chmod as 755 to be executed)
# DEPLOY SOLUTION 1 

    export GIT_DIR=/git/repo-bare.git
    export GIT_BRANCH1=master
    export GIT_TARGET1=/var/www/html
    export GIT_BRANCH2=dev
    export GIT_TARGET2=/var/www/dev
    echo "GIT DIR:  $GIT_DIR/"
    echo "GIT TARGET1:  $GIT_TARGET1/"
    echo "GIT BRANCH1:  $GIT_BRANCH1/"
    echo "GIT TARGET2:  $GIT_TARGET2/"
    echo "GIT BRANCH2:  $GIT_BRANCH2/"
    echo ""

    cd $GIT_DIR/

while read oldrev newrev refname
do
    branch=$(git rev-parse --abbrev-ref $refname)
    BRANCH_REGEX='^${GIT_BRANCH1}.*$'
    if [[ $branch =~ $BRANCH_REGEX ]] ; then
        export GIT_WORK_TREE=$GIT_TARGET1/.
        echo "Checking out branch: $branch";
        echo "Checking out to workdir: $GIT_WORK_TREE"; 

        git checkout -f $branch
    fi

    BRANCH_REGEX='^${GIT_BRANCH2}.*$'
    if [[ $branch =~ $BRANCH_REGEX ]] ; then
        export GIT_WORK_TREE=$GIT_TARGET2/.
        echo "Checking out branch: $branch";
        echo "Checking out to workdir: $GIT_WORK_TREE"; 

        git checkout -f $branch
    fi
done

SOLUÇÃO DE IMPLANTAÇÃO 2

#!/bin/bash 
#  /git-repo/hooks/post-receive - file content on server (chmod as 755 to be executed)
# DEPLOY SOLUTION 2

    export GIT_DIR=/git/repo-bare.git
    export GIT_BRANCH1=master
    export GIT_TARGET1=/var/www/html
    export GIT_BRANCH2=dev
    export GIT_TARGET2=/var/www/dev
    export GIT_TEMP_DIR1=/tmp/deploy1
    export GIT_TEMP_DIR2=/tmp/deploy2
    echo "GIT DIR:  $GIT_DIR/"
    echo "GIT TARGET1:  $GIT_TARGET1/"
    echo "GIT BRANCH1:  $GIT_BRANCH1/"
    echo "GIT TARGET2:  $GIT_TARGET2/"
    echo "GIT BRANCH2:  $GIT_BRANCH2/"
    echo "GIT TEMP DIR1:  $GIT_TEMP_DIR1/"
    echo "GIT TEMP DIR2:  $GIT_TEMP_DIR2/"
    echo ""

    cd $GIT_DIR/

while read oldrev newrev refname
do
    branch=$(git rev-parse --abbrev-ref $refname)
    BRANCH_REGEX='^${GIT_BRANCH1}.*$'
    if [[ $branch =~ $BRANCH_REGEX ]] ; then
        export GIT_WORK_TREE=$GIT_TARGET1/.
        echo "Checking out branch: $branch";
        echo "Checking out to workdir: $GIT_WORK_TREE"; 

        # DEPLOY SOLUTION 2: 
        cd $GIT_DIR/; mkdir -p $GIT_TEMP_DIR1; 
        export GIT_WORK_TREE=$GIT_TEMP_DIR1/.
        git checkout -f $branch
        export GIT_WORK_TREE=$GIT_TARGET1/.
        rsync $GIT_TEMP_DIR1/. -v -q --delete --delete-after -av $GIT_TARGET1/.
        rm -rf $GIT_TEMP_DIR1
    fi

    BRANCH_REGEX='^${GIT_BRANCH2}.*$'
    if [[ $branch =~ $BRANCH_REGEX ]] ; then
        export GIT_WORK_TREE=$GIT_TARGET2/.
        echo "Checking out branch: $branch";
        echo "Checking out to workdir: $GIT_WORK_TREE"; 

        # DEPLOY SOLUTION 2: 
        cd $GIT_DIR/; mkdir -p $GIT_TEMP_DIR2; 
        export GIT_WORK_TREE=$GIT_TEMP_DIR2/.
        git checkout -f $branch
        export GIT_WORK_TREE=$GIT_TARGET2/.
        rsync $GIT_TEMP_DIR2/. -v -q --delete --delete-after -av $GIT_TARGET2/.
        rm -rf $GIT_TEMP_DIR2
    fi
done

Ambas as soluções são baseadas em soluções anteriores disponíveis neste segmento.

Observe que o BRANCH_REGEX = '^ $ {GIT_BRANCH1}. Filtros $ 'para os nomes das filiais correspondentes a "mestre sequência " ou "dev *" e implementa a árvore de trabalho, se a ramificação enviada corresponder. Isso possibilita implantar uma versão dev e uma versão master em diferentes locais.

A IMPLANTAÇÃO SOLUÇÃO 1 remove apenas os arquivos que fazem parte do repositório e foi removida por uma confirmação. É mais rápido que o Deployment Solution 2.

A IMPLANTAÇÃO SOLUÇÃO 2 tem a vantagem de remover todos os novos arquivos do diretório de produção, que foram adicionados no servidor, independentemente de terem sido adicionados ao repositório ou não. Será sempre uma limpeza do repositório. É mais lento que a Solução de Implantação 1.

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.