Como fazer upgrade da Apigee híbrida para a versão 1.10

Este procedimento abrange o upgrade da versão híbrida 1.9.x da Apigee para a versão híbrida 1.10.5 da Apigee e de versões anteriores da versão híbrida 1.10.x para a versão 1.10.5.

Use os mesmos procedimentos para upgrades de versão secundária (por exemplo, 1.9 para 1.10) e para upgrades de versão de patch (por exemplo, 1.10.0 para 1.10.5).

Como fazer upgrade para a versão 1.10.5

O upgrade para a Apigee híbrida versão 1.10 pode exigir inatividade:

Ao fazer upgrade do controlador da Apigee para a versão 1.10.5, todas as implantações da Apigee passam por uma reinicialização gradual. Para minimizar a inatividade em ambientes híbridos de produção durante uma reinicialização gradual, verifique se você está executando pelo menos dois clusters (na mesma ou diferente região/data center). Divida todo o tráfego de produção para um único cluster. Pegue o cluster que você está prestes a fazer upgrade off-line e continue o processo de upgrade. Repita o processo para cada cluster.

A Apigee recomenda que você faça upgrade de todos os clusters o mais rápido possível para reduzir as chances de impacto na produção. Não há limite de tempo para o upgrade de todos os clusters restantes depois do upgrade do primeiro. No entanto, até que todos os clusters restantes sejam atualizados, as seguintes operações serão afetadas:

O backup e a restauração do Cassandra não funcionam com versões mistas. Por exemplo, um backup da versão híbrida 1.9 não pode ser usado para restaurar uma instância da versão híbrida 1.10.
O streaming de dados do Cassandra não funcionará entre versões híbridas mistas. Portanto, os clusters do Cassandra não podem ser escalonados horizontalmente.
A expansão e a desativação de regiões serão afetadas porque essas operações dependem do fluxo de dados do Cassandra.

Os procedimentos para fazer upgrade da Apigee híbrida são organizados nas seguintes seções:

Prepare-se para o upgrade.
Instale o ambiente de execução híbrido versão 1.10.5.

Pré-requisitos

Estas instruções de upgrade presumem que você tenha a Apigee híbrida versão 1.9.x instalada e queira fazer upgrade para a versão 1.10.5. Se você estiver atualizando de uma versão anterior, consulte as instruções sobre Como fazer upgrade da Apigee híbrida para a versão 1.9.

Preparar para fazer upgrade para a versão 1.10

Fazer backup da instalação híbrida (recomendado)

Estas instruções usam a variável de ambiente APIGEECTL_HOME para o diretório no seu sistema de arquivos em que você instalou apigeectl. Se necessário, mude o diretório para seu diretório apigeectl e defina a variável com o seguinte comando:
Linux
```
export APIGEECTL_HOME=$PWD
echo $APIGEECTL_HOME
```
Mac OS
```
export APIGEECTL_HOME=$PWD
echo $APIGEECTL_HOME
```
Windows
```
set APIGEECTL_HOME=%CD%
echo %APIGEECTL_HOME%
```
Faça uma cópia de backup do diretório $APIGEECTL_HOME/ da versão 1.9. Por exemplo:
```
tar -czvf $APIGEECTL_HOME/../apigeectl-v1.9-backup.tar.gz $APIGEECTL_HOME
```
Faça o backup do banco de dados Cassandra seguindo as instruções em Backup e recuperação do Cassandra.

Fazer upgrade da versão do Kubernetes

Verifique a versão da plataforma do Kubernetes e, se necessário, faça upgrade para uma versão compatível com as versões híbridas 1.9 e 1.10. Siga a documentação da plataforma se precisar de ajuda.

Clique para expandir uma lista de plataformas compatíveis

	1.10 ⁽³⁾	1.11	1.12
GKE no Google Cloud	1.24.x 1.25.x 1.26.x 1.27.x^{(≥ 1.10.5)} 1.28.x^{(≥ 1.10.5)}	1.25.x 1.26.x 1.27.x 1.28.x^{(≥ 1.11.2)} 1.29.x^{(≥ 1.11.2)}	1.26.x 1.27.x 1.28.x 1.29.x^{(≥ 1.12.1)}
GKE na AWS	1.13.x (K8s v1.24.x) 1.14.x (K8s v1.25.x) 1.26.x⁽¹²⁾ 1.27.x^{(≥ 1.10.5)} 1.28.x^{(≥ 1.10.5)}	1.14.x (K8s v1.25.x) 1.26.x⁽¹²⁾ 1.27.x 1.28.x^{(≥ 1.11.2)} 1.29.x^{(≥ 1.11.2)}	1.26.x⁽¹²⁾ 1.27.x 1.28.x 1.29.x^{(≥ 1.12.1)}
GKE no Azure	1.13.x 1.14.x 1.26.x⁽¹²⁾ 1.27.x^{(≥ 1.10.5)} 1.28.x^{(≥ 1.10.5)}	1.14.x 1.26.x⁽¹²⁾ 1.27.x 1.28.x^{(≥ 1.11.2)} 1.29.x^{(≥ 1.11.2)}	1.26.x⁽¹²⁾ 1.27.x 1.28.x 1.29.x^{(≥ 1.12.1)}
Google Distributed Cloud (somente software) no VMware ⁽¹⁾ ⁽¹³⁾	1.13.x 1.14.x 1.15.x (K8s v1.26.x) 1.16.x (K8s v1.27.x) 1.27.x^{(≥ 1.10.5)} 1.28.x^{(≥ 1.10.5)}	1.14.x 1.15.x (K8s v1.26.x) 1.16.x (K8s v1.27.x) 1.28.x^{(≥ 1.11.2)} 1.29.x^{(≥ 1.11.2)}	1.15.x (K8s v1.26.x) 1.16.x (K8s v1.27.x) 1.28.x⁽¹²⁾ 1.29.x^{(≥ 1.12.1)}
Google Distributed Cloud (somente software) em bare metal ⁽¹⁾	1.13.x 1.14.x (K8s v1.25.x) 1.15.x (K8s v1.26.x) 1.16.x (K8s v1.27.x) 1.27.x⁽¹²⁾^{(≥ 1.10.5)} 1.28.x^{(≥ 1.10.5)}	1.14.x 1.15.x (K8s v1.26.x) 1.16.x (K8s v1.27.x) 1.28.x⁽¹²⁾^{(≥ 1.11.2)} 1.29.x^{(≥ 1.11.2)}	1.15.x (K8s v1.26.x) 1.16.x (K8s v1.27.x) 1.28.x⁽¹²⁾ 1.29.x^{(≥ 1.12.1)}
EKS⁽⁷⁾	1.24.x 1.25.x 1.26.x 1.27.x^{(≥ 1.10.5)} 1.28.x^{(≥ 1.10.5)}	1.25.x 1.26.x 1.27.x 1.28.x^{(≥ 1.11.2)} 1.29.x^{(≥ 1.11.2)}	1.26.x 1.27.x 1.28.x 1.29.x^{(≥ 1.12.1)}
AKS⁽⁷⁾	1.24.x 1.25.x 1.26.x 1.27.x^{(≥ 1.10.5)} 1.28.x^{(≥ 1.10.5)}	1.25.x 1.26.x 1.27.x 1.28.x^{(≥ 1.11.2)} 1.29.x^{(≥ 1.11.2)}	1.26.x 1.27.x 1.28.x 1.29.x^{(≥ 1.12.1)}
OpenShift⁽⁷⁾	4.11 4.12 4.14^{(≥ 1.10.5)} 4.15^{(≥ 1.10.5)}	4.12 4.13 4.14 4.15^{(≥ 1.11.2)} 4.16^{(≥ 1.11.2)}	4.12 4.13 4.14 4.15 4.16^{(≥ 1.12.1)}
Rancher Kubernetes Engine (RKE)	v1.26.2+rke2r1 1.27.x^{(≥ 1.10.5)} 1.28.x^{(≥ 1.10.5)}	v1.26.2+rke2r1 v1.27.x 1.28.x^{(≥ 1.11.2)} 1.29.x^{(≥ 1.11.2)}	v1.26.2+rke2r1 v1.27.x 1.28.x 1.29.x^{(≥ 1.12.1)}
VMware Tanzu	N/A	N/A	v1.26.x
Componentes	1.10	1.11	1.12
Anthos Service Mesh	1.17.x⁽¹⁰⁾	1.18.x⁽¹⁰⁾	1.19.x⁽¹⁰⁾
JDK	JDK 11	JDK 11	JDK 11
cert-manager.	1.10.x 1.11.x 1.12.x	1.11.x 1.12.x 1.13.x	1.11.x 1.12.x 1.13.x
Cassandra	3.11	3.11	4.0
Kubernetes	1.24.x 1.25.x 1.26.x	1.25.x 1.26.x 1.27.x	1.26.x 1.27.x 1.28.x
kubectl			1.27.x 1.28.x 1.29.x
Helm	3.10+	3.10+	3.14.2+
Driver CSI do Secret Store		1.3.4	1.4.1
Vault		1.13.x	1.15.2
⁽¹⁾ No Anthos local (Google Distributed Cloud) versão 1.13, siga estas instruções para evitar conflitos com o `cert-manager`: Instalação conflitante do cert-manager ⁽²⁾ Suporte disponível para a Apigee híbrida versão 1.8.4 e mais recentes. ⁽³⁾ As datas de EOL oficiais da Apigee híbrida versões 1.10 e anteriores foram atingidas. Os patches mensais regulares não estão mais disponíveis. Essas versões não têm mais suporte oficial, exceto para clientes com exceções explícitas e oficiais para suporte contínuo. Outros clientes precisam fazer o upgrade. ⁽⁴⁾O Anthos no local (Google Distributed Cloud) nas versões 1.12 e anteriores não tem suporte. Consulte a Política de suporte de versões do Distributed Cloud em Bare Metal e a lista de versões compatíveis do Distributed Cloud on VMware. ⁽⁵⁾O Google Distributed Cloud em bare metal ou VMware requer o Anthos Service Mesh 1.14 ou mais recente. Recomendamos que você faça upgrade para a versão híbrida v1.8 e mude para o gateway de entrada da Apigee, que não requer mais a instalação do Anthos Service Mesh no cluster híbrido. ⁽⁶⁾ Suporte disponível para a versão híbrida da Apigee 1.8.4 e mais recentes. ⁽⁷⁾ Não há suporte na Apigee híbrida 1.8.4 e mais recentes. ⁽⁸⁾ Suporte disponível para a Apigee híbrida versão 1.7.6 e mais recentes. ⁽⁹⁾ Não há suporte na Apigee híbrida versão 1.8.5 e mais recentes. ⁽¹⁰⁾ O Anthos Service Mesh é instalado automaticamente com a Apigee híbrida 1.9 e mais recentes. ⁽¹¹⁾ Suporte disponível para a Apigee híbrida versão 1.9.2 e mais recentes. ⁽¹²⁾ Agora os números de versão do GKE na AWS refletem as versões do Kubernetes. Consulte Suporte a versões e upgrades do GKE Enterprise para conferir detalhes da versão e os patches recomendados. ⁽¹³⁾ O Vault não é certificado em Google Distributed Cloud for VMware. ⁽¹⁴⁾ Suporte disponível para a Apigee híbrida versão 1.10.5 e mais recentes. ⁽¹⁵⁾ Suporte disponível para a Apigee híbrida versão 1.11.2 e mais recentes. ⁽¹⁶⁾ Suporte disponível para a Apigee híbrida versão 1.12.1 e mais recentes.

Sobre os clusters anexados

Para a Apigee híbrida versão 1.7.x e anteriores, é necessário usar os clusters anexados do GKE quando você quer executar a Apigee híbrida em um contexto multicloud no Elastic Kubernetes Service (EKS), no Azure Kubernetes Service (AKS) ou em outro provedor de serviços de terceiros do Kubernetes com suporte. O anexo do cluster permite que o Google meça o uso do Anthos Service Mesh.

Para a versão híbrida da Apigee 1.8.x, os clusters anexados ao GKE são obrigatórios se você estiver usando o Anthos Service Mesh no seu gateway de entrada. Se você estiver usando o gateway de entrada da Apigee, os clusters anexados serão opcionais.

Instalar o ambiente de execução híbrido 1.10.5

Verifique se você está no diretório base híbrido (o pai do diretório em que o arquivo executável apigeectl está localizado):
```
cd $APIGEECTL_HOME/..
```

Faça o download do pacote de lançamento do seu sistema operacional usando o seguinte comando. Selecione sua plataforma na tabela a seguir:

Linux

Linux de 64 bits:

curl -LO \
  https://storage.googleapis.com/apigee-release/hybrid/apigee-hybrid-setup/1.10.5/apigeectl_linux_64.tar.gz

Mac OS

Mac 64 bits:

curl -LO \
  https://storage.googleapis.com/apigee-release/hybrid/apigee-hybrid-setup/1.10.5/apigeectl_mac_64.tar.gz

Windows

Windows 64 bit:

curl -LO ^
  https://storage.googleapis.com/apigee-release/hybrid/apigee-hybrid-setup/1.10.5/apigeectl_windows_64.zip

Renomeie o diretório apigeectl/ atual para um nome de diretório de backup. Exemplo:

Linux

mv $APIGEECTL_HOME/ $APIGEECTL_HOME-v1.9/

Mac OS

mv $APIGEECTL_HOME/ $APIGEECTL_HOME-v1.9/

Windows

rename %APIGEECTL_HOME% %APIGEECTL_HOME%-v1.9

Extraia o conteúdo do arquivo gzip baixado para seu diretório base híbrido. O diretório base híbrido é aquele em que o diretório renomeado apigeectl-v1.9 está localizado:
Linux
```
tar xvzf filename.tar.gz -C ./
```
Mac OS
```
tar xvzf filename.tar.gz -C ./
```
Windows
```
tar xvzf filename.zip -C ./
```
O conteúdo de tar é, por padrão, expandido em um diretório com a versão e a plataforma no nome. Por exemplo, ./apigeectl_1.10.5-xxxxxxx_linux_64. Renomeie esse diretório para apigeectl usando o seguinte comando:
Linux
```
mv apigeectl_1.10.5-xxxxxxx_linux_64 apigeectl
```
Mac OS
```
mv apigeectl_1.10.5-xxxxxxx_mac_64 apigeectl
```
Windows
```
rename apigeectl_1.10.5-xxxxxxx_windows_64 apigeectl
```
Altere para o diretório apigeectl:
```
cd ./apigeectl
```
Esse diretório é o diretório inicial apigeectl. É lá que o comando executável apigeectl está localizado.
Estas instruções usam a variável de ambiente $APIGEECTL_HOME para o diretório no seu sistema de arquivos em que o utilitário apigeectl está instalado. Se necessário, mude o diretório para seu diretório apigeectl e defina a variável com o seguinte comando:
Linux
```
export APIGEECTL_HOME=$PWD
```
```
echo $APIGEECTL_HOME
```
Mac OS
```
export APIGEECTL_HOME=$PWD
```
```
echo $APIGEECTL_HOME
```
Windows
```
set APIGEECTL_HOME=%CD%
```
```
echo %APIGEECTL_HOME%
```
Verifique a versão de apigeectl com o comando version:
```
./apigeectl version
```
```
Version: 1.10.5
```
Crie um diretório hybrid-base-directory/hybrid-files e acesse-o. O diretório hybrid-files é onde estão localizados os arquivos de configuração, como os arquivos de substituição, certificados e contas de serviço. Por exemplo:
Linux
```
mkdir $APIGEECTL_HOME/../hybrid-files
```
```
cd $APIGEECTL_HOME/../hybrid-files
```
Mac OS
```
mkdir $APIGEECTL_HOME/../hybrid-files
```
```
cd $APIGEECTL_HOME/../hybrid-files
```
Windows
```
mkdir %APIGEECTL_HOME%/../hybrid-files
```
```
cd %APIGEECTL_HOME%/../hybrid-files
```
Verifique se kubectl está definido para o contexto correto usando o seguinte comando. O contexto atual precisa ser definido como o cluster em que você está fazendo upgrade da Apigee híbrida.
```
kubectl config get-contexts | grep \*
```
No diretório hybrid-files:
1. Atualize os seguintes links simbólicos para $APIGEECTL_HOME. Com esses links, você pode executar o comando apigeectl recém-instalado no diretório hybrid-files:
```
ln -nfs $APIGEECTL_HOME/tools tools
ln -nfs $APIGEECTL_HOME/config config
ln -nfs $APIGEECTL_HOME/templates templates
ln -nfs $APIGEECTL_HOME/plugins plugins
```
2. Para verificar se os links simbólicos foram criados corretamente, execute este comando e certifique-se de que os caminhos do link apontam para os locais corretos:
```
ls -l | grep ^l
```
Faça a seguinte mudança no arquivo overrides.yaml para ativar o gráfico apigee-operator usando a tag correta, 1.10.5-hotfix.1:
```
  ao:
    image:
      url: "gcr.io/apigee-release/hybrid/apigee-operators"
      tag: "1.10.5-hotfix.1"
  
```
Faça uma inicialização a seco para verificar se há erros:
```
${APIGEECTL_HOME}/apigeectl init -f OVERRIDES_FILE --dry-run=client
```
Em que OVERRIDES_FILE é o nome do arquivo de substituições, por exemplo, ./overrides/overrides.yaml.

Dica: é possível substituir OVERRIDES_FILE no exemplo de código acima pelo nome e caminho do arquivo de substituição, e todas as instâncias desta página serão substituídas.
Se não houver erros, inicialize o híbrido 1.10.5:
```
$APIGEECTL_HOME/apigeectl init -f OVERRIDES_FILE
```
Observação: apigeectl instala e configura o gateway de entrada da Apigee quando você executa apigeectl init.
Verifique o status da inicialização:
```
$APIGEECTL_HOME/apigeectl check-ready -f OVERRIDES_FILE
```
Em caso de sucesso, a saída vai ser: All containers ready.
```
kubectl describe apigeeds -n apigee
```
Na saída, procure State: running.
Verifique se há erros com uma simulação do comando apply usando a sinalização --dry-run:
```
$APIGEECTL_HOME/apigeectl apply -f OVERRIDES_FILE --dry-run=client
```
Se não houver erros, aplique as substituições. Selecione e siga as instruções para ambientes de produção ou ambientes sem produção, dependendo da sua instalação.
Produção

Para ambientes de produção, você precisa fazer upgrade de cada componente híbrido individualmente e verificar o status do componente atualizado antes de seguir para o próximo componente.
1. Verifique se você está no diretório hybrid-files.
2. Aplique as modificações para fazer upgrade do Cassandra:
  $APIGEECTL_HOME/apigeectl apply -f OVERRIDES_FILE --datastore
3. Verifique a conclusão:
  $APIGEECTL_HOME/apigeectl check-ready -f OVERRIDES_FILE
  Dica: se check-ready falhar, você poderá receber mais informações sobre seus pods com:
  kubectl -n NAMESPACE get pods
  
  Em que NAMESPACE é seu namespace da Apigee híbrida.
  Passe para a próxima etapa somente quando os pods estiverem prontos.
4. Aplique as modificações para fazer upgrade dos componentes de telemetria e verificar a conclusão:
  $APIGEECTL_HOME/apigeectl apply -f OVERRIDES_FILE --telemetry
  $APIGEECTL_HOME/apigeectl check-ready -f OVERRIDES_FILE
5. Acesse os componentes do Redis:
  $APIGEECTL_HOME/apigeectl apply -f OVERRIDES_FILE --redis
6. Aplique as modificações para fazer upgrade dos componentes no nível da organização (MART, Watcher e Apigee Connect) e verifique a conclusão:
  $APIGEECTL_HOME/apigeectl apply -f OVERRIDES_FILE --org
  $APIGEECTL_HOME/apigeectl check-ready -f OVERRIDES_FILE
7. Aplique as modificações para fazer upgrade dos seus ambientes. Você tem duas opções:
  - Ambiente por ambiente: aplique suas modificações em um ambiente por vez e verifique a conclusão. Repita esta etapa para cada ambiente:
    $APIGEECTL_HOME/apigeectl apply -f OVERRIDES_FILE --env ENV_NAME
    
    $APIGEECTL_HOME/apigeectl check-ready -f OVERRIDES_FILE
    
    Em que ENV_NAME é o nome do ambiente que você está atualizando.
  - Todos os ambientes de uma só vez: aplique suas modificações a todos os ambientes de uma só vez e verifique a conclusão:
    $APIGEECTL_HOME/apigeectl apply -f OVERRIDES_FILE --all-envs
    
    $APIGEECTL_HOME/apigeectl check-ready -f OVERRIDES_FILE
8. Aplique as modificações para fazer upgrade dos componentes virtualhosts de telemetria e verificar a conclusão:
  $APIGEECTL_HOME/apigeectl apply -f OVERRIDES_FILE --settings virtualhosts
  $APIGEECTL_HOME/apigeectl check-ready -f OVERRIDES_FILE
Sem produção

Na maioria dos ambientes de produção, de demonstração ou experimental, é possível aplicar as substituições a todos os componentes de uma só vez. Se o ambiente de não produção for grande e complexo, ou imita frequentemente um ambiente de produção, use as instruções para fazer upgrade dos ambientes de produção.
1. Verifique se você está no diretório hybrid-files.
2. $APIGEECTL_HOME/apigeectl apply -f OVERRIDES_FILE
3. Verifique o status:
  $APIGEECTL_HOME/apigeectl check-ready -f OVERRIDES_FILE

Como reverter um upgrade

Siga estas etapas para reverter um upgrade anterior:

Limpe os jobs concluídos do namespace do ambiente de execução híbrido, em que NAMESPACE é o namespace especificado no arquivo de modificações, se você especificou um namespace. Caso contrário, o namespace padrão é apigee:
```
kubectl delete job -n NAMESPACE \
  $(kubectl get job -n NAMESPACE \
  -o=jsonpath='{.items[?(@.status.succeeded==1)].metadata.name}')
```

Limpe jobs concluídos do namespace apigee-system:

kubectl delete job -n apigee-system \
  $(kubectl get job -n apigee-system \
  -o=jsonpath='{.items[?(@.status.succeeded==1)].metadata.name}')

Altere a variável APIGEECTL_HOME para apontar para o diretório que contém a versão original de apigeectl. Por exemplo:
```
export APIGEECTL_HOME=PATH_TO_PREVIOUS_APIGEECTL_DIRECTORY
```
No diretório raiz da instalação para a qual você quer reverter, execute apigeectl apply, verifique o status dos pods e execute apigeectl init. Use o arquivo de modificações original da versão para a qual você quer reverter:
1. No diretório de arquivos híbridos, execute apigeectl apply:
```
$APIGEECTL_HOME/apigeectl apply -f ORIGINAL_OVERRIDES_FILE
```
  Em que ORIGINAL_OVERRIDES_FILE é o caminho relativo e o nome do arquivo de substituições para a instalação híbrida da versão anterior, por exemplo, ./overrides/overrides1.9.yaml.
2. Verifique o status dos seus pods.
```
kubectl -n NAMESPACE get pods
```
  Em que NAMESPACE é seu namespace da Apigee híbrida.
3. Verifique o status de apigeeds:
```
kubectl describe apigeeds -n apigee
```
  A saída será semelhante a esta:
```
Status:
  Cassandra Data Replication:
  Cassandra Pod Ips:
    10.8.2.204
  Cassandra Ready Replicas:  1
  Components:
    Cassandra:
      Last Successfully Released Version:
        Revision:  v1-f8aa9a82b9f69613
        Version:   v1
      Replicas:
        Available:  1
        Ready:      1
        Total:      1
        Updated:    1
      State:        running
  Scaling:
    In Progress:         false
    Operation:
    Requested Replicas:  0
  State:                 running
```
  Siga para a próxima etapa somente quando o pod apigeeds estiver em execução.
4. Execute o comando a seguir para anotar quais serão os novos valores de contagem da réplica para o processador de mensagens após o upgrade. Se esses valores não corresponderem ao que você definiu anteriormente, altere os valores no arquivo de substituições para corresponder à configuração anterior.
```
apigeectl apply -f ORIGINAL_OVERRIDES_FILE --dry-run=client --print-yaml --env ENV_NAME 2>/dev/null |grep "runtime:" -A 25 -B 1| grep "autoScaler" -A 2
```
  A saída será semelhante a esta:
```
      autoScaler:
        minReplicas: 2
        maxReplicas: 10
```
5. Execute apigeectl init:
```
$APIGEECTL_HOME/apigeectl init -f ORIGINAL_OVERRIDES_FILE
```

Como fazer upgrade da Apigee híbrida para a versão 1.10

Como fazer upgrade para a versão 1.10.5

Pré-requisitos

Preparar para fazer upgrade para a versão 1.10

Fazer backup da instalação híbrida (recomendado)

Linux

Mac OS

Windows

Fazer upgrade da versão do Kubernetes

Clique para expandir uma lista de plataformas compatíveis

Componentes

Sobre os clusters anexados

Instalar o ambiente de execução híbrido 1.10.5

Linux

Mac OS

Windows

Linux

Mac OS

Windows

Linux

Mac OS

Windows

Linux

Mac OS

Windows

Linux

Mac OS

Windows

Linux

Mac OS

Windows

Produção

Sem produção

Como reverter um upgrade