Skip to content

Instantly share code, notes, and snippets.

@rafaelcorreiapoli
Last active March 26, 2018 07:16
Show Gist options
  • Save rafaelcorreiapoli/4e38ba8793f37e756572894be3c03e66 to your computer and use it in GitHub Desktop.
Save rafaelcorreiapoli/4e38ba8793f37e756572894be3c03e66 to your computer and use it in GitHub Desktop.
Workspaces

Workspaces

Descrição alto nível

Um workspace é um conjunto de configurações salvas pelo desenvolvedor que descrevem um cenário de trabalho que ele configurou e que vai querer ser retomado no futuro, seja por ele ou por outros engenheiros. Exemplo: O desenvolvedor está trabalhando no fluxo de pagamento de boletos e, para isto, precisa dos seguintes serviços:

  • Blackleach v1.0.5
  • Stormshield v2.0.2
  • Griswold v1.0.5
  • Horadric v5.0.1

É interessante que ele possa subir estes serviços no seu cluster de maneira rápida e prática toda vez que for trabalhar neste fluxo de pagamento de boletos. Estes workspaces podem ser públicos ou privados. Quando é público, fica disponível para ser reutilizado por outros engenheiros.

Gerenciamento

Estes workspaces são gerenciados pelo SOIL

Persistência

Para sua persistência, será utilizado o banco de dados. Este banco de dados será um Deployment no namespace formicarium, mesmo namespace onde está o SOIL.

Chaveamento entre Workspaces

Buscando a otimização de recursos no cluster, não queremos manter vivos no cluster serviços que o desenvolvedor não está utilizando. Partindo desta premissa, quando o desenvolvedor muda do workspace A para o workspace B, devemos definir qual é a mínima operação para que o namespace do usuário tenha os serviços desejados. Para isto, devemos remover os serviços que eram do workspace A e não estão no workspace B e subir os serviços do workspace B que não estavam no workspace A. (Lembrando que um serviço é identificado por um nome + versão)

Relação com testes

Para que um testes seja executado, ele precisa ter um conjunto pré-definidos de serviços rodando em seu namespace. Desta maneira, podemos associar cada teste à um workspace para que o executor de testes saiba quais serviços deve subir antes de executar o teste. Quando um desenvolvedor opta por rodar um conjunto de testes, podemos fazer algumas otimizações no provisionamento de serviços para que estes testes sejam executados o mais rápido possível. Não é possível reaproveitar serviços utilizados em um teste para o teste seguinte, já que o teste assume que o sistema está num estado inicial, porém, já é possível ir provisionando os serviços associados ao workspace do próximo teste enquanto um teste é executado.

SDL

type Workspace {
  services: [Service]
  owner: User
  isPublic: Boolean
}
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment