Recentemente a JetBrains entrou com uma proposta muito interessante, o Space: um ambiente que centraliza os recursos mais importantes para o desenvolvimento de software, sem largar coisas importantes para as demais equipes, que podem não estarem envolvidas com códigos.
Antes de entrarmos nos tópicos, quero ressaltar que não sou patrocinado pela JetBrains, falo aqui apenas da minha experiência.
Planos
Primeiro vamos falar dos diferentes planos que a JetBrains oferece para o Space, e o que oferecem (no momento que escrevi esse artigo).
Inicial
O JetBrains Space tem um plano inicial, gratuito, que oferece:
- 2.000 créditos de CI por mês (vou explicar como funcionam).
- 10GB de armazenamento total.
- 50GB de transferência de dados por mês.
- 20.000 mensagens pesquisáveis.
- 10 aplicações ou integrações.
- Usuários e projetos ilimitados (dentro dos limites de armazenamento).
Time
Um plano inicial, porém um pouquinho mais robusto, focado em pequenas equipes ou times de organização pequena (pode ser utilizado em organizações maiores, mas talvez não irá suprir as necessidades de todos).
Ele oferece:
- 4.000 créditos de CI por mês (em contraste com os 2000 do plano inicial).
- 10GB de armazenamento, por usuário.
- 50GB de transferência, por usuário, por mês.
- Número ilimitado de mensagens pesquisáveis.
- 20 aplicações ou integrações.
- Número ilimitado de usuários e projetos.
A forma de cobrança desse plano é por usuário, por mês. No caso de necessitar de mais armazenamento ou transferência, só adicionar mais usuários, mesmo sem ter necessariamente mais usuários, que será cobrado normalmente por um usuário adicional (bem simples no meu ponto de vista).
Organização
Para organizações, com maiores requisitos e maiores equipes, eles oferecem um plano bem generoso:
- 20.000 créditos de CI por mês
- 25GB de armazenamento, por usuário.
- 125GB de transferência, por usuário.
- Mensagens pesquisáveis, aplicações e integrações ilimitadas.
- Usuários e projetos ilimitados.
A forma de cobrança é igual, por usuário, por mês.
Empresas
E, por fim, o plano mais robusto de todos, fornecendo:
- All Products Pack (um pacote com todos produtos da JetBrains, detalhe, isso é diferente de todos os serviços, a página explica melhor).
- 50.000 créditos de CI, por mês.
- 100GB de armazenamento, por usuário.
- 500GB de transferência, por usuário.
- Mensagens pesquisáveis, aplicações e integrações ilimitadas.
- Usuários e projetos ilimitados
Cobrado por usuário, por mês.
Cobrança
Todos produtos podem ser cobrados mensalmente, ou anualmente, com o desconto que a JetBrains fornece, em quase todos seus serviços e produtos.
Recursos adicionais
Em cada plano, é listado apenas os recursos, digamos, mais importantes, mais chamativos. Porém existem outros recursos que variam de plano para plano.
O plano para times, fornece autenticação por meio do Google e GitHub, espelhamento de repositórios (como Docker, Maven e NuGet), meetings privadas, possibilidade de comprar mais créditos de CI, dentre outros.
O plano para organizações, fornece mais integrações, quality gate, autenticação por SAML, AD, OAuth2, revisão de código de múltiplos repositórios, além de ter todos os recursos do plano de times.
Já o enterprise ainda tem muita coisa por vir, apesar de já fornecer aprovações de ausência, onboarding, e alguns recursos menores, muitos são recursos planejados. É o plano com menor número de diferenciais, por enquanto, já que o Space tem muita coisa para melhorar, como toda ferramenta, mas muito mais por estar começando.
Para ver os planos, e os recursos, disponíveis, você pode clicar nesse link.
O que vou tratar aqui?
Vou falar da minha experiência com CI deles, juntamente com os pacotes.
O Space fornece muitas coisas, tentam diminuir o máximo de distração e troca de contexto, para tirar maior proveito da produtividade.
Eles fornecem recursos de Chat, Boards, Documentações, Code Review, Pull Request, Issues, Blogs, Times. Muito do que a gente já conhece e já viu em outras ferramentas, mas de uma maneira diferente, totalmente integrada.
O meu foco aqui é totalmente o CI deles, contando a minha experiência com a ferramenta.
Créditos CI
Uma unidade de Crédito de CI equivale a um minuto da máquina, com os recursos padrões, que você pode ver aqui. O uso desse crédito pode diminuir caso opte por máquinas menores, sempre prevalecendo o recurso mais caro na conta.
Para um plano gratuito, achei 2.000 créditos de CI o bastante. Porém eu gostaria de ver um plano individual com recursos como Repositórios públicos de pacotes, que só é disponibilizado no plano de organização, e com mais créditos de CI.
Configuração
A configuração do CI é por meio de um arquivo .space.kts, utilizando a linguagem de scripting Kotlin, muito parecida com o que utilizamos agora com Gradle + Kotlin DSL.
Ao configurar seu primeiro job, ele será automaticamente acionado a cada push, isso mesmo, não precisa de configuração adicional para dizer quais são os triggers, o trigger inicial é um push no repositório git.
Caso queira filtrar para acontecer apenas quando o push for para alguma branch, você pode utilizar Regex para definir o padrão das branches que o job irá rodar:
Você usar tanto o + para inclusão, como o - para fazer uma exclusão:
Além de outras sintaxes para incluir e excluir branches, isso utilizando o poder da linguagem Kotlin.
Apesar de utilizarmos o gradlew como um step do nosso job, podemos também utilizar containers e rodar scripts bash:
Lembrando que seu repositório está clonado na workdir, em outras palavras, você pode rodar scripts que estão no seu repositório, para compilar seus projetos.
Repositório de pacotes
Agora vamos falar de outro cara interessante: os repositórios de pacotes. O JetBrains Space permite criar repositórios para imagens Docker, Maven, NuGet e RPM.
Com isso, você é capaz de construir o seu projeto, criar uma imagem Docker e enviar direto para o repositório do Space, e, a partir de lá, fazer o pull desses pacotes onde você precisa que eles estejam, como no seu servidor container-based.
Eu me bati um pouco nesse passo, até encontrar uma forma de fazer ele funcionar. O Space ainda está em construção, e isso é visível, algumas coisas ainda precisam de uma abordagem muito mais “bruta”, como nesse caso.
Para conseguir criar uma imagem Docker do meu projeto Kotlin, primeiro configurei o plugin shadowJar para criar um jar com todas bibliotecas, que será exportado para build/libs/, depois criei meu Dockerfile:
E agora vem a parte interessante da brincadeira, descobri que o Space não permite utilizar o Docker nos seus Jobs, porém, ele fornece uma API para construir suas imagens e enviar ao repositório, depois de brincar bastante consegui chegar nisso:
Com isso consegui automatizar a criação de publicação da minha imagem no registro.
Um ponto interessante a ressaltar é que, dado que o Job roda dentro do mesmo projeto do Space que o registro está, você não precisa configurar a autenticação, pois isso já funciona, como o esperado, e como outras ferramentas permitem.
O que eu gostei
Kotlin
Gostei a possibilidade de utilizar Kotlin, me lembra muito quando o Gradle veio para trazer uma forma diferente de gerenciamento de build e dependências, por especificação, por meio de uma linguagem de programação, me lembra também o que o Jenkins permite fazer.
Simplicidade
Curti a simplicidade, não precisei configurar triggers, apenas fiz meu primeiro job e já estava rodando a cada push. Configurar o build de uma imagem Docker foi interessante, não muito intuitivo, tive que queimar uns créditos tentando até conseguir, ter que copiar para um diretório compartilhado para poder utilizar em outro step faz sentido, mostra que temos uma isolação de steps, seria interessante no futuro podermos fazer isso com mais facilidade.
Docker e containers
Gostei de poder utilizar imagens Docker. Recentemente comecei a me apaixonar pela tecnologia, mesmo já entendendo ele desde o começo, nunca cheguei a por as mãos e ver em ação. E meu primeiro contato foi em um MacOS, Docker “virtualizado”, desempenho a desejar, mas funcional, tive uma primeira impressão não muito boa, espero que isso mude nos M1 (já temos Docker nativo nos BSD, mas só roda imagens com base no BSD, e já temos o Jail, etc, etc…). Apesar disso, Docker traz tanto liberdade quanto segurança.
Liberdade
E como falei de liberdade, gostei da liberdade, obviamente. Imagina, utilizar Kotlin e configurar nossos Jobs e Steps com base em diferentes parâmetros, podendo observar o resultado dos Steps e reagir de forma diferente. Bom, Jenkins permite isso, espero que o Space vá bem mais longe, e estou gostando até agora.
Integração
Os jobs se integram com seus projetos, aparecem nos commits quando falham, e quando sucedem. Uma ferramenta importante para pull requests, e code review. Além de ser possível configurar verificações exteriores e se integrar com os repositórios de pacotes.
Pontos a melhorar
Desempenho
O desempenho ainda deixa a desejar. A JetBrains tem trabalhado duro nisso, e é, pelo menos no YouTrack, a tarefa com a maior prioridade: Critica.
Um Job simples demora 2 minutos para completar, realmente é um pouco atrás do que já temos, mas o que promete e o que oferece, vale a pena experimentar e aguardar (ansiosamente) pelas melhorias.
Eu não percebi aumento significativo quando o Step precisa de mais poder de processamento ou menos, apenas para iniciar eles que demora um tempinho, que ele fica em “Idle”.
Estou confiante que isso irá melhorar, está bem no começo, mas tem me agradado bastante.
Recursos simples
Dar Trigger em um Job quando uma Tag for enviada é algo que estou bastante ansioso, tanto quantos as melhorias de performance. Consegui driblar criando uma branch para cada release e usando Regex, como demonstrei, funciona, mas ainda quero as tags.
A facilidade em construir imagens Docker e publicar, seria interessante rodar o Docker no nosso Job, mas isso envolve um trabalho tremendo e alguns possíveis pontos sobre segurança, a se considerar. Mas uma sintaxe mais fácil com a possibilidade de configurar uma espécie de Storage para os Steps, permitiria podermos compartilhar os arquivos entre eles sem precisar de scripts em bash copiando pra lá e pra cá.
Aproveitar melhor o Kotlin
Aproveitar melhor a natureza estática da linguagem para garantir que os scripts estão corretos, os scripts bash introduzem liberdade, em troca de precisar serem testados para saber se irá funcionar, já que o Space é um “Ambiente desconhecido”.
Com a verificação do script mais rápida e mais poderosa, seria mais fácil descobrir se um Job vai falhar ou suceder antes mesmo de rodar ele, economizando poder de processamento de créditos de CI.
Possibilidade de rodar os Jobs localmente
Já falaram que será possível, e estou ansioso para isso. Poder testar na minha máquina, utilizando meus recursos, se o Job irá funcionar no Space, sem ter que enviar minhas mudanças, ajudaria bastante na previsibilidade dos resultados.
Conclusão
O JetBrains Space está bem no começo, me lembra bastante quando comecei a programar em Kotlin, algumas coisas não compilavam, o código produzido para a JVM não era tão performático, o Plugin era um pouquinho lento, o compilador também. A documentação gerada pelo Dokka não era tão robusta e o Kapt falhava bastante. Os genéricos tinham alguns probleminhas. Porém, a cada release, era uma melhora considerável, e vejo que o mesmo será com o Space.
O Space entrega sim o que promete, entrei para testar quando estava no beta, mas não fiz muita coisa, não consegui perceber quanta mudança já foi feita até aqui, e quero acompanhar essa evolução de perto. Admiro que a JetBrains tenha essa abordagem, de liberar os recursos em desenvolvimento, resolver os problemas das pessoas, mesmo sabendo das limitações atuais. Ótimo para nós, temos a oportunidade de testar tecnologias incríveis, e ótimo para eles, que com base no nosso feedback, melhoram cada vez mais.
A conclusão é que vale utilizar o Space sim, muitos recursos já funcionam muito bem, como Code Review, Chats, Repositórios, Pacotes, o que melhorar sempre terá, e é bom vermos de perto e testarmos cada coisa nova que chegar, direto do forno (haha).
Com isso estarei iniciando uma nova série, periodicamente trazendo as novidades do JetBrains Space, e minha experiência com ele!
