Passagens a produção – léxico IT

Está na altura de explicar aqui algum do jargão utilizado na minha profissão, e alguns cocó shits frequentes – expressão não da minha autoria, mas muito utilizada pela minha pessoa para denominar bugs de variadas espécies.

Trabalho na área da Web, onde muito rapidamente podemos pôr coisas online e disponíveis para todos os utilizadores do site. Ou seja, se alguma coisa estiver mal, rapidamente podemos corrigir.

No entanto, muito raramente trabalhamos directamente sobre o site que está live – não queremos que os utilizadores do site vejam trabalho em progresso, tudo partido, etc.

Então, geralmente existem os seguintes ambientes de desenvolvimento, muito por alto:

  • Local – no meu computador tenho um ambiente montado onde trabalho. Só eu posso ver este ambiente.
  • Desenvolvimento – ambiente onde o resto da equipa também põe as suas alterações, e onde se testa para ver se não há conflitos.
  • Qualidade – já não tenho um ambiente destes há anos, mas a ideia é ser um ambiente onde há dados reais e onde a malta do negócio possa validar e uma determinada funcionalidade pedida está OK e como eles pediram.
  • Produção – o ambiente live, disponível para todos os utilizadores, com funcionalidades que passaram em todos os testes nos ambientes anteriores. Não convém haver erros neste ambiente, embora hajam SEMPRE bugs, como em qualquer software.

Portanto, quando eu falo em “subidas a produção”, “passagem a produção” ou “deploys”, quer dizer que estamos a pôr coisas novas online.

Dependendo dos sítios, há malta que defende que devia haver só uma subida por semana, outros que defendem que deve haver muitas. Eu sou pelos deploys frequentes, porque é mais fácil perceber onde se deu o cocó shit. Já estive em sítios onde se faziam passagens a produção semanalmente e era o fim do mundo sempre que aconteciam – tudo rebentava, por mais testado que estivesse, porque há sempre alguma coisa que é diferente no ambiente de produção e que não conseguimos prever.

Também há o caso em que determinadas coisas só podem ficar live a partir de uma determinada hora. Já tive de fazer deploys de madrugada. Não é agradável.

Posto isto, já falei neste blog das passagens a produção à sexta-feira. Porque são elas o Satanás desta área?

Em qualquer sítio que tenha um site live, com utilizadores e com um mínimo de reputação a manter, evitam-se os deploys à sexta-feira. Há quem diga que só não se faz deploys na sexta à tarde, outros o dia inteiro – actualmente, onde trabalho, é suposto não pormos nada em produção à sexta.

O motivo é relativamente simples: se por acaso alguma coisa é posta online e se revela problemática, o pessoal vai andar todo em stress para resolver antes do fim de semana. Também pode acontecer não se notar logo o bug, e durante o fim de semana é suposto alguém ir corrigir.

Muitas vezes dizem-me “oh pah é só alterar um texto”, e eu digo NÃO. Porque o alterar um texto é simples e não provoca estragos, à partida. Mas imaginem que outra coisa, que não previmos, vai também nesse deploy. Ou que o texto parte o styling (CSS) da página. Pumbas, tudo estragado, e lá vou eu ter de ir em modo bombeira apagar o fogo enquanto já só penso no fim de semana.

Resumindo, não há deploys à sexta-feira porque existe sempre um risco de dar merda, e não queremos merda a suceder durante o fim de semana. E planeamos a nossa semana e trabalho com isso em mente.

Esta regra também se aplica à hora de saída durante a semana. É tremendamente irresponsável meter coisas online e bazar pouco tempo depois, ou mesmo antes do deploy acabar, e vejo isso a acontecer com alguma frequência. Depois dá merda, e quem resolve? O Cristo que fica a trabalhar até às 21h.

Notem que acima, sublinhei o supostamente não pormos nada live à sexta. Isto é porque a malta do negócio gosta de viver na emoção, e muitas vezes pede paridelas MEGA URGENTES E QUE TÊM DE ESTAR LIVE NO FIM DE SEMANA.

70% das vezes que estas mega caganeiras acontecem, dá mesmo merda. Pessoalmente, quando estou em stress e sob pressão para resolver uma coisa grave em produção, demoro o triplo do tempo para a resolver do que em circunstâncias normais.

Concluindo: não se devem fazer passagens a produção à sexta-feira à tarde ou o dia inteiro, porque o risco de cocó shit acontecer é demasiado elevado e estragar o fim de semana a toda a gente.

Ainda hoje

Vem o chefe à minha beira e diz:

“Olá Miss IT, olha, vinha falar-te sobre o ticket XYZ”

(ticket XYZ tinha acabado de ser passado para mim)

“Sim….”

“É para explicar, pessoa A precisa disso”

“Mas era para pôr online agora?”

“Sim”

“Ai valha-me Deus”

E ele riu-se.

Para referência, não se deve meter coisas online (o termo é em ambiente de produção) a uma sexta-feira, porque se houver problemas o site fica com problemas o fim de semana todo… ou então resgatam-nos do fim de semana. É uma regra transversal a todas as empresas em que estive. Um dia hei-de fazer um post sobre isso.

Marketing, sempre o marketing

Como poderão ou não saber, no meu currículo consta uma experiência numa agência de marketing enquanto web developer que, apesar de ter sido o sítio onde fui mais feliz a nível profissional, me deu também uma ideia concreta do caos que é a malta do marketing.

Em qualquer empresa que estive, a malta do marketing é sempre a malta que não se organiza. O planeamento que devia existir não existe, dá a ideia que molham um dedo, vêem em que direcção está o vento, e tomam decisões com base nisso, tudo sempre para ontem. E depois somos nós, os ITs, que temos de dizer que não é humanamente possível alterar X às 18h de uma sexta-feira.

Óbvio que isto é uma generalização exageradíssima, mas a ideia é mais ou menos essa. Não há um sítio por onde eu tenha passado onde 90% das paridelas não venham das equipas de marketing.

A mais recente está agora a decorrer. Alguém se lembrou que devíamos fazer um rebranding aos sites, aplicações e afins. Acho óptimo e já não era sem tempo, tínhamos um logo que parecia dos tempos antes das Torres Gémeas caírem.

Com isto, decidem fazer um design completamente novo para um dos sites, que implica basicamente reconstruir o site do zero. Tudo bem, também estava a precisar.

O tema aqui? Decidiram isso há umas 2 semanas. Para esse novo site ter sido lançado ontem. Quando há 2 semanas a equipa de Web tinha trabalho em mãos, e coisas que não podia largar de um momento para o outro, portanto ao início só o nosso team leader é que começou a trabalhar nesse projecto. Spoiler alert: 2 semanas não chegam, e toda a gente foi avisada disso. Avançaram na mesma com o projecto.

Agora já perceberam que o site não vai avançar a tempo com o rebranding novo – no shit! Ok, vamos pelo menos alterar o logo no site actual.

Quando é que isto é decidido? Ontem ao fim do dia, quando fui informada que eu é que iria fazer essa alteração. E querem que segunda-feira às 8h da manhã esteja live.

“Ok, quando é que o design me pode passar os logos, para deixar tudo pronto para fazer o deploy na segunda-feira de manhã?”

“Ele vai-te mandando conforme ele vá tendo as imagens prontas”

Portanto, é para ter isto a sair segunda-feira de manhã cedo mas ainda não há nada preparado!

Hoje vou a falar com o designer e pergunto:

“Tens ideia de quantas imagens são? Como são para o site X e Y ainda devem ser algumas”

“Site Y não, vai haver um site novo para Y”

“Hmmm tens a certeza? É melhor confirmar com o marketing”

Portanto, o designer não sabia que tinha de fazer também logos novos para Y, porque não foi informado pelo marketing. E eu tenho de fazer uma alteração que envolve o site todo, mas não tenho os materiais para tal.

E, no meio deste processo, o marketing esqueceu-se de um dos produtos, pelo que por pouco todos os produtos tinham rebranding excepto um.

Entendem a génese da desorganização aqui?