Software Público Brasileiro

Oi pessoal,

Criei dois novos repositórios no OBS: isv:spb:stable e isv:spb:devel.

'stable' é uma cópia de isv:spb:v3 (nosso repositório atual) e 'devel' é uma branch[2] de stable.

Como não estamos entregando releases, seria interessante estruturarmos o repositório em um sistema mais próximo de rolling releases[1]. Para isso os passos abaixo foram baseados (de forma simplificada) no processo de manutenção de pacotes da rolling release do openSUSE, o Factory. Deste modo:

* Os ambientes dev, prod e homologa, do MPOG, apontariam para o repositório stable (o dev aqui por não termos acesso ao homologa?).
* Os ambientes de desenvolvimento (incluindo cdtc, local e lappis) apontariam para devel.
* A equipe de devops sobe pacotes para 'devel', e enviam requests para que as alterações sejam incluídas em stable (isso funciona como merge requests no gitlab, ver [ocs submitrequest]).
* Após testar os novos pacotes nos ambientes de desenvolvimento, os requests são aceitos (pelos seniors ou outra pessoa que não a que gerou o request) em 'stable' e os ambientes do MPOG são atualizados.

O repositório não está pronto para que apontemos para os mesmos, pois os schedulers do OBS estavam fora do ar neste fim de semana:

> 16:54 < athos> is it normal to take a long time (like a day) for a repository to be created and start building my packages?
> 17:18 < tittiatcoke> athos: The x86_64 schedulers are down since Saturday

Se o esquema acima for aceito, podemos apontar todos os ambientes para 'stable' de imediato e utilizar a task de 'bootsrap_common' para apontar os ambientes de dev para devel.

feedback?

Obrigado.

[1] https://en.wikipedia.org/wiki/Rolling_release
[2] o OBS suporta um esquema de branches, parecido com os forks do gitlab, sempre que um pacote é alterado na stable, ele também é alterado na devel, mas o oposto não acontece.

--
Athos Ribeiro

http://ccsl.ime.usp.br/
http://lappis.unb.br/

Massa,

acho que isso vai funcionar!

=)

Em 13 de setembro de 2015 20:26, Athos Ribeiro
escreveu:

> Oi pessoal,
>
> Criei dois novos repositórios no OBS: isv:spb:stable e isv:spb:devel.
>
> 'stable' é uma cópia de isv:spb:v3 (nosso repositório atual) e 'devel' é
> uma branch[2] de stable.
>
> Como não estamos entregando releases, seria interessante estruturarmos o
> repositório em um sistema mais próximo de rolling releases[1]. Para isso os
> passos abaixo foram baseados (de forma simplificada) no processo de
> manutenção de pacotes da rolling release do openSUSE, o Factory. Deste modo:
>
> * Os ambientes dev, prod e homologa, do MPOG, apontariam para o
> repositório stable (o dev aqui por não termos acesso ao homologa?).
> * Os ambientes de desenvolvimento (incluindo cdtc, local e lappis)
> apontariam para devel.
> * A equipe de devops sobe pacotes para 'devel', e enviam requests para que
> as alterações sejam incluídas em stable (isso funciona como merge requests
> no gitlab, ver [ocs submitrequest]).
> * Após testar os novos pacotes nos ambientes de desenvolvimento, os
> requests são aceitos (pelos seniors ou outra pessoa que não a que gerou o
> request) em 'stable' e os ambientes do MPOG são atualizados.
>
> O repositório não está pronto para que apontemos para os mesmos, pois os
> schedulers do OBS estavam fora do ar neste fim de semana:
>
> > 16:54 < athos> is it normal to take a long time (like a day) for a
> repository to be created and start building my packages?
> > 17:18 < tittiatcoke> athos: The x86_64 schedulers are down since Saturday
>
> Se o esquema acima for aceito, podemos apontar todos os ambientes para
> 'stable' de imediato e utilizar a task de 'bootsrap_common' para apontar os
> ambientes de dev para devel.
>
> feedback?
>
> Obrigado.
>
> [1] https://en.wikipedia.org/wiki/Rolling_release
> [2] o OBS suporta um esquema de branches, parecido com os forks do gitlab,
> sempre que um pacote é alterado na stable, ele também é alterado na devel,
> mas o oposto não acontece.
>
> --
> Athos Ribeiro
>
>http://ccsl.ime.usp.br/
>http://lappis.unb.br/
> _______________________________________________
> spb-dev mailing list
> spb-dev@listas.softwarepublico.gov.br
>https://listas.softwarepublico.gov.br/mailman/cgi-bin/listinfo/spb-dev
>



--

*Arthur de Moura Del Esposte*
Engenheiro de Software

CCSL/IME - http://ccsl.ime.usp.br/
LAPPIS - http://fga.unb.br/lappis
Colivre - http://colivre.coop.br/

Eu só acho um pouco arriscado usar o mesmo repositório para o dev, homologa
e produção. Na prática se hoje estamos colocando em dev quer dizer que não
é pra ir pra produção ainda. Isso parece que inviabiliza testarmos algo em
dev quando sabemos que teremos que fazer deploy. Outro caso seria o oposto:
estarmos testando algo no dev e temos que fazer alguma atualização urgente
o que não seria possível pois ao convergir estaríamos colocando os pacotes
ainda não testados em produção.



On Mon, Sep 14, 2015 at 11:00 AM Arthur Del Esposte
wrote:

> Massa,
>
> acho que isso vai funcionar!
>
> =)
>
> Em 13 de setembro de 2015 20:26, Athos Ribeiro
> escreveu:
>
>> Oi pessoal,
>>
>> Criei dois novos repositórios no OBS: isv:spb:stable e isv:spb:devel.
>>
>> 'stable' é uma cópia de isv:spb:v3 (nosso repositório atual) e 'devel' é
>> uma branch[2] de stable.
>>
>> Como não estamos entregando releases, seria interessante estruturarmos o
>> repositório em um sistema mais próximo de rolling releases[1]. Para isso os
>> passos abaixo foram baseados (de forma simplificada) no processo de
>> manutenção de pacotes da rolling release do openSUSE, o Factory. Deste modo:
>>
>> * Os ambientes dev, prod e homologa, do MPOG, apontariam para o
>> repositório stable (o dev aqui por não termos acesso ao homologa?).
>> * Os ambientes de desenvolvimento (incluindo cdtc, local e lappis)
>> apontariam para devel.
>> * A equipe de devops sobe pacotes para 'devel', e enviam requests para
>> que as alterações sejam incluídas em stable (isso funciona como merge
>> requests no gitlab, ver [ocs submitrequest]).
>> * Após testar os novos pacotes nos ambientes de desenvolvimento, os
>> requests são aceitos (pelos seniors ou outra pessoa que não a que gerou o
>> request) em 'stable' e os ambientes do MPOG são atualizados.
>>
>> O repositório não está pronto para que apontemos para os mesmos, pois os
>> schedulers do OBS estavam fora do ar neste fim de semana:
>>
>> > 16:54 < athos> is it normal to take a long time (like a day) for a
>> repository to be created and start building my packages?
>> > 17:18 < tittiatcoke> athos: The x86_64 schedulers are down since
>> Saturday
>>
>> Se o esquema acima for aceito, podemos apontar todos os ambientes para
>> 'stable' de imediato e utilizar a task de 'bootsrap_common' para apontar os
>> ambientes de dev para devel.
>>
>> feedback?
>>
>> Obrigado.
>>
>> [1] https://en.wikipedia.org/wiki/Rolling_release
>> [2] o OBS suporta um esquema de branches, parecido com os forks do
>> gitlab, sempre que um pacote é alterado na stable, ele também é alterado na
>> devel, mas o oposto não acontece.
>>
>> --
>> Athos Ribeiro
>>
>>http://ccsl.ime.usp.br/
>>http://lappis.unb.br/
>> _______________________________________________
>> spb-dev mailing list
>> spb-dev@listas.softwarepublico.gov.br
>>https://listas.softwarepublico.gov.br/mailman/cgi-bin/listinfo/spb-dev
>>
>
>
>
> --
> *Arthur de Moura Del Esposte*
> Engenheiro de Software
>
> CCSL/IME - http://ccsl.ime.usp.br/
> LAPPIS - http://fga.unb.br/lappis
> Colivre - http://colivre.coop.br/
> _______________________________________________
> spb-dev mailing list
> spb-dev@listas.softwarepublico.gov.br
>https://listas.softwarepublico.gov.br/mailman/cgi-bin/listinfo/spb-dev
>