Ir para conteúdo

POWERED BY:

Arquivado

Este tópico foi arquivado e está fechado para novas respostas.

aline_

[Resolvido] Ambiente para testes PHP

Recommended Posts

Bom dia pessoal,

 

Desenvolvi um sistema empresarial que inicialmente era simples, mas hoje está com 4 módulos e crescendo.

Pra acompanhar o crescimento precisei mudar minha estrutura de arquivos. Estou tentando usar o git, porque até agora ele era só meu, mas logo terei ajuda.

 

Como podem imaginar, tenho várias pastas com a versão oficial, em testes, bkp... Com um controle de versão, qual a melhor forma de ter um ambiente teste?

Hoje eu altero local, testo na minha máquina e depois dos testes repasso as alterações para o arquivo oficial e subo pelo ftp. (Tá, na verdade as vezes faço direto no oficial.)

É um saco, porque tenho aquivos de conexão diferentes (local e oficial), locais diferentes para salvar os relatórios e outros detalhes que funcionam no meu ambiente mas não no hospedado e vice-versa. Nunca tenho certeza de que os arquivos estão sincronizados, porque não posso simplesmente sobrepor a pasta.

 

Quem trabalha com esse tipo de sistema faz como? Tem um ambiente para testes local, ou dois ambientes hospedados? Tem tudo tão bem organizado que as diferenças influenciam em um arquivo ou dois?

 

Enfim... se é pra fazer, que seja do jeito certo. Só preciso saber qual é.

Compartilhar este post


Link para o post
Compartilhar em outros sites

Hummmmmmmmm...

 

Olha não sei se tem um padrão pra isso... mas eu desenvolvo a intranet aqui da empresa da seguinte forma, no meu computador local eu tenho uma cópia fiel da base oficial, altero, crio etc, nessa base local, depois apenas mando os arquivos que foram criados/alterados e altero alguma estrutura ou outra do banco... pelo menos nunca me perdi nessa questão... :grin:

Compartilhar este post


Link para o post
Compartilhar em outros sites

O "ideal" seria ter o seguinte cenário:

- ambiente de desenvolvimento (geralmente local, ou seja, na sua máquina);

- ambiente de testes (para testar o desenvolvimento de toda a equipe, se houver);

- ambiente de homologação (para homologar as alterações que vão para o git).

 

Deu pra perceber que o ambiente de homologação deve ser o mais próximo possível do ambiente de produção? Este ambiente deve ser utilizado pela equipe que vai homologar o funcionamento dos módulos, nesta equipe não é composta de técnicos de informática, mas por técnicos das áreas de negócio.

 

O ambiente de produção receber apenas as atualizações direto do git.

 

Quanto a arquivos diferentes, bem, você pode usar arquivos de configuração diferentes, mais ou menos como arquivos .INI, e ter um arquivo desse para cada um dos seus ambientes.

 

Caso lembre de mais alguma coisa eu volto.

Compartilhar este post


Link para o post
Compartilhar em outros sites

Aline, só de começar já é algum progresso.

 

Bom, uma vez que já há um repositório git, pode se livrar dos backups, sem medo de ser feliz.

 

Se você for sincronizar os repositórios entre 'computadores', provavelmente tem uma estrutura Unix Like montada com acesso a SSH. Espero que entenda ou encontre uma forma de entender o que estou dizendo.

 

Agora entramos no nível de complexidade/automaticidade que você deseja agregar ao fluxo de desenvolvimento. Quanto mais automatizado você quiser, mais coisas terá que fazer. Vou dar uma sugestão partindo do simples:

 

No GIT, há uma forma de você criar linhas de desenvolvimento, chamdas branches. No sistema que trabalho atualmente, cada característica do sistema é um branch separado. Quando você tiver ajuda, cada pessoa pode pegar um item pra fazer, vamos dizer assim.

 

Depois, juntamos as características numa linha comum de desenvolvimento. Este é o branch que todo desenvolvedor deve se concentrar. É neste branch que são realizados os testes pois ele agrega todas as funcionalidades do sistema.

 

Tudo devidamente testado localmente, há um novo branch. Aqui chamamos de homologação, mas pode ser testes, por exemplo. Como citado pelo @Prog, o servidor de homologação é uma cópia fiel do servidor de produção. Nele simulamos o comportamento do sistema com os dados reais, dos clientes/usuários para garantir que não haverá perda de dados após uma atualização, ou encontrar uma forma de evitar isso.

 

Por último, temos o branch produção. É apenas este branch que o servidor de produção segue. Se precisar de detalhes com as configurações, procure por 'application deploy with git'. Há várias formas muito fáceis de se conseguir isso.

Compartilhar este post


Link para o post
Compartilhar em outros sites

Legal! Obrigada pelas explicações ;)

Quanto as diferenças, acho que estou fazendo tempestade. Só tirar um tempo pra organizar tudo, e acho que só vai sobrar o arquivo de conexão mesmo.

 

Mas a linha de homologação seria direto no servidor então?

Mais 'amadoramente' falando, teria www.sitema.com/ e www.sitema.com/homologacao? Dois bancos hospedados?

Compartilhar este post


Link para o post
Compartilhar em outros sites

Legal! Obrigada pelas explicações ;)/>

Quanto as diferenças, acho que estou fazendo tempestade. Só tirar um tempo pra organizar tudo, e acho que só vai sobrar o arquivo de conexão mesmo.

 

Mas a linha de homologação seria direto no servidor então?

Mais 'amadoramente' falando, teria www.sitema.com/ e www.sitema.com/homologacao? Dois bancos hospedados?

 

perfeitamente.

Compartilhar este post


Link para o post
Compartilhar em outros sites

×

Informação importante

Ao usar o fórum, você concorda com nossos Termos e condições.