DEV Community: Virtual360

Como aceleramos em 90% a execução das nossas migrações em Rails

Augusto Pagnossim Frigo — Wed, 03 Sep 2025 21:04:09 +0000

Nota: Este post também está disponível em inglês.

Ao usar Rails, todos precisamos criar, deletar ou reverter migrations, já que são um recurso necessário para estruturar o banco de dados ao construir sua aplicação. Migrations, no entanto, enfrentam um problema de escalabilidade: quanto mais migrations são adicionadas, mais tempo leva para executá-las para refletir as mudanças no schema do banco de dados. Além disso, se você troca de branch e executa alguma migration, seu schema.rb pode ficar com resquícios de outras branches, o que pode forçar você a recriar todo o banco de dados. Esse processo não é particularmente problemático em projetos pequenos, mas no nosso caso, com 6 anos de migrations, reconstruir o banco demorava muito. Além disso, como usamos muitos bancos de dados diferentes com o mesmo schema, criar novos bancos estava ficando lento, tornando a criação de novos ambientes mais trabalhosa do que deveria.

Ao buscar soluções para esse problema, a primeira ideia pode ser tentar otimizar o código das migrations de alguma forma. Otimizar o código das migrations ajuda em parte, mas não traria uma melhoria significativa na velocidade.

Primeiro, precisamos considerar que, por padrão, cada migration no Rails é executada em uma nova transaction, o que faz sentido. Você não quer lidar com uma migration pela metade em seu sistema de produção. No entanto, essa abordagem cria problemas de performance, já que executar migrations sequencialmente, cada uma em sua própria transaction, pode ficar muito lento conforme o número de migrations aumenta. No nosso caso, precisamos criar novos ambientes frequentemente, e esses novos ambientes precisam ser migrados e populados do zero. Além disso, muitas vezes os desenvolvedores podem precisar trocar de uma branch para outra e eles precisam reconstruir todo o banco de dados se não quiserem incluir resquícios indesejados no schema.rb.

Além da questão da transaction, quando rodamos uma migration, o Rails adiciona seu timestamp na tabela schema_migrations. Para verificar se uma migration já foi executada, o Rails pega o timestamp da migration e tenta encontrar esse timestamp na tabela. Se encontrar, a migration é pulada; caso contrário, ela é executada. Note que o Rails verifica o timestamp da migration em relação ao conteúdo da tabela, mas o inverso não ocorre. Ou seja, não há problema em ter entradas na tabela que não existem na pasta migrate, e podemos adicionar um timestamp manualmente se não quisermos rodar uma migration em um ambiente específico.

Percebemos que, embora nossas migrations fossem muito lentas, o schema:load era rápido, muito mais rápido que executar as migrations. Porém, a task schema:load não era adequada para ambientes de produção. O schema:load não é capaz de criar views nem executar código Ruby presente nas migrations. Por exemplo, se tivéssemos um código SQL criando uma view, ela não seria criada no schema:load. Além disso, algumas migrations executavam código Ruby para criar registros (User.create!(name: 'John'), por exemplo), e seria arriscado ignorar essas criações sem garantir que estavam presentes no seeds.
O desafio, então, era carregar o schema e ainda assim criar esses registros que só as migrations conseguiam. Trouxemos, assim, uma solução que engloba o melhor dos dois lados.

Atenção: considere que essa solução remove a vantagem de ser agnóstico em relação ao banco de dados que o schema.rb oferece. Ao gerar o arquivo .sql, você está criando um arquivo que funciona para o seu adaptador de banco atual, não necessariamente para outros. Além disso, essa solução pode não ser recomendada se você não tem um grande problema com migrations lentas, especialmente porque o Rails não possui suporte oficial a esse tipo de otimização, e manter o histórico e a reversibilidade das migrations pode ser melhor na maioria dos casos.

A primeira ideia foi criar um arquivo .sql que fizesse o mesmo que as migrations e então carregá-lo. Pensamos em usar o structure.sql como solução, já que o schema.rb não reflete a criação de views, mas o structure.sql sim. Também precisávamos limitar quais migrations seriam transformadas em SQL puro, pois queríamos poder reverter facilmente as mais recentes se necessário, e garantir que todos os ambientes já tivessem rodado as migrations que seriam convertidas. Como percebemos que todos os ambientes já tinham rodado todas as migrations de 2024, decidimos manter todas até 2024 como baseline. Todas as migrations de 2025 em diante não seriam convertidas para SQL puro e continuariam sendo executadas normalmente.

No entanto, essa solução tinha um problema: o structure.sql não reflete registros criados ou atualizados durante as migrations. Embora seja esperado que os desenvolvedores sempre criem uma cópia dos updates/creates no seeds.rb quando necessário em novos ambientes, não havia garantia de que todo create/update que deveria ser portado estava refletido no seeds. Precisávamos então rastrear quais migrations tinham esse problema, mas tínhamos literalmente milhares de migrations e ler uma a uma não era viável nem seguro. Por isso, precisávamos rastrear automaticamente quais migrations faziam insert ou update, para pelo menos excluir da análise as que não criavam registros, que eram a maioria. Criamos então um initializer que só roda durante o processo de migration e loga quais migrations fazem esse tipo de operação. Note que esse initializer foi gerado por IA e não segue as melhores práticas, mas foi usado uma vez e removido do código, então tudo bem.

config/initializers/migration_data_logger.rb

if defined?(ActiveRecord::Migration)
  module MigrationDataLogger
    class << self
      attr_accessor :enabled

      def start_logging
        @enabled = true
        @log_file = File.open(Rails.root.join('log/migration_data_changes.log'), 'a')
        @current_migration = nil
        puts 'Migration logging started - writing to log/migration_data_changes.log'
      end

      def stop_logging
        @enabled = false
        @log_file&.close
        puts 'Migration logging stopped'
      end

      def log(message)
        return unless @enabled

        @log_file.puts "[#{Time.current}] #{@current_migration}: #{message}"
        @log_file.flush
      end

      def set_migration(migration)
        @current_migration = "#{migration.version} - #{migration.name}"
      end
    end
  end

  ActiveSupport::Notifications.subscribe('sql.active_record') do |_, started, finished, _, payload|
    MigrationDataLogger.log("#{payload[:sql]}") if MigrationDataLogger.enabled && payload[:sql] =~ /^(INSERT|UPDATE|DELETE)/i
  end

  ActiveRecord::Migration.prepend(Module.new do
    def migrate(direction)
      MigrationDataLogger.start_logging
      MigrationDataLogger.set_migration(self)
      super
      MigrationDataLogger.stop_logging
    end
  end)
end

Com os nomes dessas migrations em mãos, reduzimos de milhares para apenas 70 o número de migrations que precisaríamos analisar manualmente. Foi um número bom para análise manual, então não avançamos mais com o script, mas uma forma mais automatizada seria capturar todos os SQLs executados e descartar os que afetaram zero linhas. Depois disso, movemos todo o código que estava em migrations mas funcionava como seed para o db/seeds.rb, e finalmente pudemos nos livrar das migrations antigas sem nos preocupar com os registros criados.

Após mapear o que deveria ser movido para o seeds, começamos o processo de obter o SQL pré-2025. O primeiro passo foi adicionar a seguinte linha ao application.rb:

config.active_record.schema_format = :sql

Depois, movemos todas as migrations pós-2024 para outra pasta (para não serem executadas), e reconstruímos o banco. Assim, obtivemos um arquivo SQL que refletia todas as migrations pré-2025 e podia ser facilmente carregado. Esse novo arquivo, chamado structure.sql, foi renomeado para structure_baseline.sql.
Depois disso, deletamos todas as migrations pré-2025 e devolvemos as pós-2024 para a pasta migrate.
Em seguida, geramos manualmente uma migration com timestamp do final de 2024, que seria executada após a última migration de 2024. Por exemplo, se a última migration tinha timestamp 20241230xxxxx, geraríamos uma com timestamp 20241231xxxx. Inserimos esse timestamp em todos os ambientes existentes editando diretamente a tabela schema_migrations. Assim, conseguimos ter uma migration que carrega todo o conteúdo do banco, mas nunca é executada em ambientes já existentes. Lembre-se: para funcionar, é preciso garantir que todos os ambientes já rodaram todas as migrations que estão sendo transformadas em SQL puro.
Com esses preparativos, criamos a seguinte migration:

class LoadBaselineSchema < ActiveRecord::Migration[7.0]
  disable_ddl_transaction!

  def change
    ActiveRecord::Base.connection.execute(File.read(Rails.root.join('db/structure_baseline.sql')))
  end
end

Atenção: repare que o disable_ddl_transaction! faz a migration rodar sem transação no banco, o que pode ser um problema dependendo do seu contexto. Provavelmente você vai querer remover essa linha (ou pelo menos condicionar para rodar só em ambiente local). Optamos por usar porque acelera bastante o carregamento do .sql e só vai rodar em ambientes novos. Se algum problema acontecer durante o carregamento, basta recriar o banco, já que é um ambiente novo.
Depois disso, removemos a linha adicionada no application.rb, já que a mudança definitiva do schema.rb para structure.sql seria feita em outro pull request para revisão adequada. Você pode explicitar no application.rb que quer usar ruby ao invés de sql, se preferir:

config.active_record.schema_format = :ruby

Queríamos então rodar as migrations para gerar novamente o schema.rb. Porém, ao tentar carregar o structure_baseline.sql, o Rails tentava recriar as tabelas padrão — ar_internal_metadata e schema_migrations. Modificamos manualmente as linhas do structure.sql
CREATE TABLE public.ar_internal_metadata e CREATE TABLE public.schema_migrations para incluir um IF NOT EXISTS.
Também tivemos problemas com os índices dessas tabelas, e adicionamos condições para só criar os índices se eles não existirem.

ALTER TABLE ONLY public.ar_internal_metadata
    ADD CONSTRAINT ar_internal_metadata_pkey PRIMARY KEY (key);
ALTER TABLE ONLY public.schema_migrations
    ADD CONSTRAINT schema_migrations_pkey PRIMARY KEY (version);

se tornou

DO $$
BEGIN
    IF NOT EXISTS (
        SELECT 1 FROM pg_constraint
        WHERE conname = 'ar_internal_metadata_pkey'
    ) THEN
        ALTER TABLE ONLY public.ar_internal_metadata
            ADD CONSTRAINT ar_internal_metadata_pkey PRIMARY KEY (key);
    END IF;
END
$$;

DO $$
BEGIN
    IF NOT EXISTS (
        SELECT 1 FROM pg_constraint
        WHERE conname = 'schema_migrations_pkey'
    ) THEN
        ALTER TABLE ONLY public.schema_migrations
            ADD CONSTRAINT schema_migrations_pkey PRIMARY KEY (version);
    END IF;
END
$$;

Deletar essas criações de tabela e índices pode ser uma solução melhor, já que o Rails as cria automaticamente, mas não testamos essa abordagem. A partir daí, o db:migrate deve funcionar.
Você também pode precisar deletar a linha COMMENT ON EXTENSION pg_trgm IS 'text similarity measurement and index searching based on trigrams'; também caso esteja rodando com um usuário sem permissão para comentar extensões.

Com essas modificações, nosso comando db:migrate ficou muito mais rápido, mostrando resultados de cerca de 90% de otimização.

How we sped up our rails migration setup in 90%

Augusto Pagnossim Frigo — Wed, 03 Sep 2025 21:03:43 +0000

This post is also available in Portuguese.

When using rails, everyone had to create, delete or rollback migrations, as they're a useful resource for structuring your database when you build your application. However, migrations suffer from a problem in terms of scalability: when you add more migrations to your project, they must be run to reflect the database changes in your schema. Moreover, if you switch between branches and run some migrations, your schema.rb may have garbage from other branches, which may force you to rebuild your entire database. This process is not particularly problematic when you have a small project, but in our case, with 6 years of migrations, rebuilding the database was taking a lot of time. Also, as we use a lot of databases that have the same schema, creating new ones was becoming slow, which caused our process of creating new environments to be more painful than it should.

When we think about solutions to this problem, the first thought may be that maybe it's possible to optimize the migration code in some way or that an easy solution may not exist. In parts, optimizing the migrations' code could help, but it wouldn't be able to speed it up significantly.

First of all, we need to consider that, by default, every migration in rails creates a new transaction. It makes sense. You don't want to deal with half migration run in your productive system. However, this approach creates performance problems, as having to execute migrations sequentially with a different transaction for every single one of them may become really slow with the amount of migrations that you have. In our case, we need to ship new environments frequently, and those new environments have to be migrated and seeded from zero. Moreover, a lot of times developers may switch from one branch to another and they have to rebuild the entire database if they don't want to commit garbage in the schema.rb.

Second, our migrations, particularly, had a lot of code that was there for historical reasons. There was lots of code like User.update_all(some_condition: true) that, once run in the productive environments that existed at the time of the migration, had no reason to be there anymore.

We noticed that, even though our migrations were significatively slow, our schema:load was fast, lots of times faster than our migration process. However, the schema:load task was not helpful to run in productive environments. schema:load is not capable of creating views, nor executing Ruby code present in migrations. For example, if we had a SQL code creating a view, it wouldn't be created in schema:load. Moreover, some migrations were executing Ruby code to create records (User.create!(name: 'John'), for instance), and it'd be risky to skip those creations without mapping if they were present in the seeds. Besides the transaction question, when we run a migration, rails adds its timestamp to the table schema_migrations. To check if a migration was previously executed or not, rails will get the timestamp of the migration being considered to run, and then try to find the same timestamp in this table. If rails is able to find the timestamp, then the migration is skipped. Otherwise, it will be executed. Notice that rails will check the timestamp of a migration against the contents of the table, but the inverse does not occur. As a conclusion, there is no problem in this table having entries that do not exist in the migrate folder, and we can add a timestamp to this table if we don't want to run a migration in a specific environment.

Our challenge was to find a way to load the schema and still be able to create those records that only migrations were capable of.

Warning: keep in mind that this solution will remove the advantage of being database-agnostic that schema.rb brings. When you generate the .sql file, you're essentially generating a .sql file that works for your current database adapter, not necessarily for other ones. Also, this solution may not be recommended if you don't have a big problem with migrations being slow, especially because rails doesn't support this way of speeding your migrations up, and keeping the changes history and reversibility may be better in most situations.

Immediately, the first thing that came to our minds was to create a .sql file that does the same as the migrations and then load it. We then thought about using structure.sql as a solution to our problem, as schema.rb is not capable of reflecting creation of views, but structure.sql does. We also needed to place a limit on which migrations would be transformed into plain sql, because we wanted to be able to easily revert the recent ones if needed, and we wanted to guarantee that all the environments we had had already run the migrations that were going to be transformed into plain sql. As we noticed that all of our environments had already run all 2024's migrations, we decided to keep every migration until 2024 as a baseline. Every migration from 2025 onwards would not be converted into plain SQL and would still run normally.

However, this solution had a problem: structure.sql doesn't reflect created or updated records during migrations. Even though it's expected that the developers always create a copy of updates/creates on seed.rb when they are necessary in new environments, we had no guarantee that every create/update that should be ported to new environments was reflected in the seeds file. We then needed to track which migrations had this problem, but we had (literally) thousands of migrations and reading them one by one was simply not viable and very error-prone. Considering this, we needed to automatically track which migrations insert or update a record, so we could at least exclude from our search all the migrations that didn't create any record, which was most of them. We then created an initializer that would only run in the migration process, and it logs which migrations create any operation of this type. Please notice that this initializer is AI generated and is not suited for best coding practices, but it was used once and not kept in our codebase, so it's fine.

config/initializers/migration_data_logger.rb

if defined?(ActiveRecord::Migration)
  module MigrationDataLogger
    class << self
      attr_accessor :enabled

      def start_logging
        @enabled = true
        @log_file = File.open(Rails.root.join('log/migration_data_changes.log'), 'a')
        @current_migration = nil
        puts 'Migration logging started - writing to log/migration_data_changes.log'
      end

      def stop_logging
        @enabled = false
        @log_file&.close
        puts 'Migration logging stopped'
      end

      def log(message)
        return unless @enabled

        @log_file.puts "[#{Time.current}] #{@current_migration}: #{message}"
        @log_file.flush
      end

      def set_migration(migration)
        @current_migration = "#{migration.version} - #{migration.name}"
      end
    end
  end

  ActiveSupport::Notifications.subscribe('sql.active_record') do |_, started, finished, _, payload|
    MigrationDataLogger.log("#{payload[:sql]}") if MigrationDataLogger.enabled && payload[:sql] =~ /^(INSERT|UPDATE|DELETE)/i
  end

  ActiveRecord::Migration.prepend(Module.new do
    def migrate(direction)
      MigrationDataLogger.start_logging
      MigrationDataLogger.set_migration(self)
      super
      MigrationDataLogger.stop_logging
    end
  end)
end

Having these migration names in hand, we reduced thousands that we'd need to analyze to just 70. It was a good number to analyze manually, so we didn't go further with the script, but a more automated way of getting the migrations would be to find some way of getting all the executed sql and its return, and discard the ones that affected zero rows. After this, we moved all the code that was in migrations but acted as a seed to db/seeds.rb, and we could finally get rid of the old migrations without having to pay attention to the records that were created.

After successfully mapping what should be moved to the seeds, we started our process of getting the pre-2025 SQL file. The first step was to add the following line to application.rb:

config.active_record.schema_format = :sql

We then moved all post-2024 migrations to another folder (so they're not run in the migrations), and rebuilt the database. This way, we got a SQL file that reflected all pre-2025 migrations and could be easily loaded. This new file, called structure.sql, was then renamed to structure_baseline.sql.

After doing this, we deleted all pre-2025 migrations and got all post-2024 ones back to our migrate folder.

We then manually generated a migration file with 2024 timestamp that would be run post our last 2024 migration. For example, if our last migration had the 20241230xxxx timestamp, we'd generate 20241231xxxx timestamp. We then inserted its timestamp in all our existing environments by directly editing the schema_migrations table. This way, we could have one migration that loads all the content of the database, but is never executed in environments that already exist. Remember that, for it to work, you have to guarantee that all your environments have already run all the migrations that are being transformed into plain sql.

With these preparations handled, we created the following migration file:

class LoadBaselineSchema < ActiveRecord::Migration[7.0]
  disable_ddl_transaction!

  def change
    ActiveRecord::Base.connection.execute(File.read(Rails.root.join('db/structure_baseline.sql')))
  end
end

Warning: please notice that the disable_ddl_transaction! makes the migration run without a transaction in the database and it may be a problem depending on your context. You'll probably want to remove this line of your code (or at least change it to disable_ddl_transaction! if Rails.env.local?). We chose to use it because it significantly speeds up the .sql loading speed and it's only going to be run in new environments. If some problem occurs in the process of loading the .sql file, we can just recreate the database, since it's a new environment.

After doing this, we then removed the application.rb's added line, since changing the final schema.rb to structure.sql was going to be held in another pull request so we are able to review the changes properly. You can explicitly tell application.rb that you want to use ruby instead of sql if you want to.

config.active_record.schema_format = :ruby

We then wanted to run the migrations so we could regenerate the schema.rb. However, when rails tried to load the structure_baseline.sql, it was trying to recreate the default tables from rails - ar_internal_metadata and schema_migrations. We then manually modified the structure.sql lines CREATE TABLE public.ar_internal_metadata and CREATE TABLE public.schema_migrations to include an IF NOT EXISTS clause.
We also had problems with the indexes of these tables, and we added conditions to only add the indexes if they don't exist.

ALTER TABLE ONLY public.ar_internal_metadata
    ADD CONSTRAINT ar_internal_metadata_pkey PRIMARY KEY (key);
ALTER TABLE ONLY public.schema_migrations
    ADD CONSTRAINT schema_migrations_pkey PRIMARY KEY (version);

became

DO $$
BEGIN
    IF NOT EXISTS (
        SELECT 1 FROM pg_constraint
        WHERE conname = 'ar_internal_metadata_pkey'
    ) THEN
        ALTER TABLE ONLY public.ar_internal_metadata
            ADD CONSTRAINT ar_internal_metadata_pkey PRIMARY KEY (key);
    END IF;
END
$$;

DO $$
BEGIN
    IF NOT EXISTS (
        SELECT 1 FROM pg_constraint
        WHERE conname = 'schema_migrations_pkey'
    ) THEN
        ALTER TABLE ONLY public.schema_migrations
            ADD CONSTRAINT schema_migrations_pkey PRIMARY KEY (version);
    END IF;
END
$$;

Deleting these table creations and index adding may be a better solution as rails automatically creates them, but we didn't test if it works. From now on, the db:migrate task should work.

You may want to delete the line COMMENT ON EXTENSION pg_trgm IS 'text similarity measurement and index searching based on trigrams'; too if you're running with a user that does not have privilege to comment on the extension.

With these modifications, our db:migrate task was significantly sped up, showing results around 90% optimization.

Mantendo seus dados segregados por Padrão

Victor Campos — Tue, 07 May 2024 21:14:46 +0000

Contexto:  Imagina que você teve uma ideia genial, criar um microblog empresarial, onde cada empresa vai poder ter seus colaboradores postando besteira e criando flamewar somente entre eles.

Você bateu na porta de 2 clientes diferentes, clientes grandes e eles adoraram a ideia, mas trouxeram para você a preocupação de algum colaborador postar algo confidencial e essa informação vazar.

Também pediram, para caso o contrato acabe, você garanta que deletou TODOS os dados deles.

Você prometeu para esses 2 clientes que isso seria possível e agora só precisa entregar.

Arquitetura de MultiTenancy e Segurança:

O jeito tradicional de criar multi tenancy, adicionando uma coluna account_id traz junto consigo uma complexidade em segurança e desempenho, como garantir que estou colocando account_id em todas as tabelas que eu realmente preciso? Como garantir que um Dev não esqueceu de adicionar essa coluna nos wheres necessários ? Como garantir índice correto nessa colunas para as queries não ficarem extremamente lentas?

No ultimo Rails World, tivemos 2 talks dedicadas a esses problemas:

Mantendo os dados dos seus clientes separados: https://www.youtube.com/watch?v=5MLT-QP4S74&list=PLHFP2OPUpCeY9IX3Ht727dwu5ZJ2BBbZP&index=17
Implementando índices compostos no Rails: https://www.youtube.com/watch?v=aOD0bZfQvoY&list=PLHFP2OPUpCeY9IX3Ht727dwu5ZJ2BBbZP&index=9

O próprio DHH tem um artigo falando que Multi Tenancy é o que torna aplicações web difíceis: https://world.hey.com/dhh/multi-tenancy-is-what-s-hard-about-scaling-web-services-dd1e0e81

 Mas, e se fosse possível programar sua aplicação como se ela não fosse Multi Tenancy, se você não tivesse que se preocupar com todas essas questões? 

Simples: Vamos ter 1 banco de dados para cada cliente.

Sim, você leu certo, a ideia por trás de ter segurança por padrão é que cada cliente seu tenha seu próprio banco de dados.

Com isso seu desenvolvedor não tem como simplesmente esquecer um filtro e disponibilizar os dados de um cliente para o outro.

Você também não tem que se preocupar em particionar o seu banco em vários shards separados e garantir indicies complicados quando uma tabela estiver completamente lotada.

Escalar o seu banco de dados? Bom, você vai conseguir escalar verticalmente normalmente, todos os bancos podem viver dentro do mesmo servidor sem aumentar custos, mas também pode escalar horizontalmente se for o caso.

Imagina que você tem um cliente muito, muito grande e ele sozinho deixa os outros clientes mais lentos? Simples, cria um servidor de banco só para ele, não importa, sua aplicação não precisa saber disso.

E o melhor, o Rails já te da hoje todas as ferramentas que você precisa:

——

1) Vamos iniciar o nossa aplicação genial com o bom e velho rails new

rails new enterprise_blog

2) Vamos gerar o nosso modelo com scafffold para facilitar a vida

rails g scaffold post body:text

3) Agora vem a magia, vamos usar a funcionalidade que o rails já dá para definir múltiplos databases:

Vamos separar as nossas migrações em 2, vamos ter os modelos da nossa aplicação e um modelo tenant que vai controlar os nossos diferentes clientes, esse modelo vai ficar um banco específico para ele, com migrações específicas para ele. O migrations_path diz para o rails que as migrações para esse banco ficam em uma pasta separada.

development:
  tenancy:
    <<: *default
    database: storage/tenancy.sqlite3
    migrations_paths: db/tenancy
  localhost:
    <<: *default
    database: storage/localhost.sqlite3
  localhost_2:
    <<: *default
    database: storage/localhost_2.sqlite3

4) Agora vamos criar as nossas tabelas principais

rails db:migrate

Pronto, nesse momento você vai reparar que o rails vai rodar a migração de criação da tabela de posts para os 2 bancos (lindo não?)

5) Agora, vamos criar o nosso modelo tenant, que vai ter a configuração do banco de dados e o domínio

rails g model tenant name:string custom_domain:string --database tenancy

Apontando que ele fica no —database tenancy o rails já cria a migração no lugar certo

6) Rodando a migração novamente, vamos ver que somente um tenancy foi criado

rails db:migrate

7) Agora vamos criar os dados dos nossos grandes clientes, o localhost e o seu grande concorrente locahost_2

rails c
=> Tenant.create(name: 'localhost', custom_domain: 'localhost')
=> Tenant.create(name: 'localhost_2', custom_domain: '127.0.0.1')

8) Agora, queremos sempre que a gente acessar localhost os dados do cliente localhost sejam mostrados, e quando a gente acessar o 127.0.0.1, os dados do localhost_2 sejam mostrados, para isso, vamos adicionar um middleware, um código que roda antes de cada requisição no rails:

# lib/middleware/tenant_selector.rb
class TenantSelector
  def initialize(app)
    @app = app
  end

  def call(env)
    if tenant = Tenant.tenant_from_env(env)
      tenant.switch do # aqui vem a magia, a requisição vai continuar dentro do tenant, não vai ser possível acessar o banco de dados de outros clientes
        @app.call(env)
      end
    else
      [404, { 'Content-Type' => 'text/html' }, ['Not Found']]
    end
  end
end

9) Agora um pouco de configuração para fazer o rails usar o nosso middleware e fazer o ActiveRecord::Base saber se conectar com cada banco configurado

No application.rb vamos adicionar

require_relative '../lib/middleware/tenant_selector'

module EnterpriseBlog
  class Application < Rails::Application
    (...)

    config.middleware.use TenantSelector # Se usar o Devise `config.middleware.insert_before Warden::Manager, TenantSelector`

    # aqui vem o segredo, para cada banco no database.yml, vamos criar um shard e o nome desse shard vai ser igual ao nome do tenant
    config.after_initialize do
      ActiveRecord::Base.connects_to(shards: ActiveRecord::Base.configurations.configs_for.select { |c| c.env_name == Rails.env }.reject { |c| c.name == 'tenancy' }.map do |c|
        [c.name.to_sym, { writing: c.name.to_sym }]
      end.to_h)
    end
    (...)
  end
end

10) E por fim, vamos implementar o nosso método de busca e switch do tenant

class Tenant < TenancyRecord
  def self.tenant_from_env(env)
    Tenant.find_by(custom_domain: env['SERVER_NAME']) # Aqui recomendo colocar um cache em memória por questões de desempenho
  end

  def switch
    ActiveRecord::Base.connected_to(role: :writing, shard: name.to_sym) do
      yield
    end
  end
end

11) Pronto,
Agora ao acessar o localhost ou 127.0.0.1, você vai ver posts diferentes, com menos de 20 linhas de código.

——————————

Obvio, nem tudo são flores, vou colocar aqui alguns tradeoffs

Atualmente aqui na empresa temos algumas centenas de banco de dados, não tem se mostrado um problema de escala para o rails/postgres gerenciar todas essas conexões, mas não sei se essa arquitetura escala para milhares de clientes, quando eu tiver esse problema eu trago aqui a solução
No nosso contexto, não temos uma feature que o cliente faz um signup e isso gera um database novo, o processo de assinatura de contrato demora alguns dias, o que é tempo suficiente para o nosso time de infra alterar o database.yml e fazer um deploy, temos planos para automatizar essa etapa, mas provavelmente não esse ano (se você pensar como fazer antes, só avisar)
Agregar os dados de todos os clientes para ter métricas gerenciais é um pouco trick e deu trabalho para o nosso time de dados, posso escrever mais sobre isso no futuro
Provavelmente você vai querer complicar um pouco e ter um current attribute para o tenant e usar ele como namespace do seu cache
- config.cache_store = :redis_cache_store, { url: ENV['REDIS_CACHE_STORE_URL'], namespace: proc { Current.tenant&.id } }
Você vai precisar fazer a mesma lógica do middleware no sidekiq, por sorte, o sidekiq também da suporte a middlewares
Isso não resolve variáveis globais, cuidado com elas
Provavelmente você vai ter que configurar um pgbouncer antes do necessário para gerenciar as conexões com o banco
Gerar um dump do schema para o rails não ter que ir verificar para cada banco que você tem: https://stackoverflow.com/questions/38778689/how-to-fix-a-slow-implicit-query-on-pg-attribute-table-in-rails

Mas, depois de 3 anos usando essa arquitetura, não temos o que reclamar, conseguimos no nosso dia a dia programar sem se preocupar com isso, no nosso nível de escala não temos problema de desempenho por conta da arquitetura e com certeza não temos as dores de cabeça de ter um tenant_id espalhado por centenas de tabelas no nosso banco de dados

Resumo: "Muito Além da Sorte"

Victor Campos — Thu, 07 Apr 2022 15:03:36 +0000

Muito Além da Sorte

Aqui na V360 buscamos criar um produto que realmente gere valor para o cliente, o que importa não é o número de feature ou o número de linhas que uma pessoa desenvolvedora digitou, mas sim o valor final gerado.

Encontrar o lugar certo onde botar os esforços não é uma tarefa fácil, longe disso. Na verdade, a maioria das empresas falham exatamente nesse ponto. Sabem fazer, mas não sabem "o que fazer".

Para nos ajudar nessa jornada, fomos buscar um pouco do conhecimento do Clayton M. Christensen, pai da Inovação Disruptiva, em seu excelente livro "Muito Além da Sorte".

Segue um resumo pessoal que fiz da leitura, compartilhado com toda a empresa e agora com vocês:

A maioria das empresas quando tenta inovar busca correlação e não causalidade

Uma pergunta melhor que se deve fazer é: Porque contratar esse produto?

Os clientes compram/usam algum produto pois eles tem um
“job to be done”.

Empresas criam processos eficientes para o que querem atingir, mas se estiverem fazendo as perguntas erradas sobre inovação, vão ser eficientes em responder as perguntas erradas.

No seu livro de maior sucesso, o dilema do inovador (ótimo livro por sinal), o autor explica porque as empresas caem perante a uma inovação disruptiva, mas não conta quais paços dar para gerá-la. Essa é a intenção desse “novo” livro.

Entender a razão que o produto foi contratado ajuda a entender os seus competidores. O livro mostra o estudo de caso de um fast food de milkshake:

Antes das 9 da manhã, os clientes contratam o milkshake para resolver o trabalho de tomar café da manhã enquanto se deslocam para o trabalho. Os competidores são uma banana, sanduíche ou mesmo doces.

Já no final da tarde, quando um pai entra com seu filho e compra um milkshake, este está competindo com todos os “nãos” que o pai deu durante a semana, e é o momento para parecer um “pai legal”.

Além de entender os competidores, analisar o trabalho que se quer fazer também leva a compreender quais características são importantes.

Se seu público alvo são os consumidores da manhã, um milkshake que cause entupimento no canudo pode ser um problema, dado que as pessoas estão dirigindo enquanto tomam. Já para o pai que quer comprar o amor do seu filho com o milkshake, mas não quer se sentir tão culpado, ter uma opção pequena ajuda.

Para inovar, precisamos escrever um currículo tanto para o nosso produto quanto para os concorrentes. Assim sabemos para qual direção queremos seguir e quais “job to be done” queremos atacar primeiro.

O market share deveria ser calculado por "job to be done" e não pela categoria do produto.

O autor cita o exemplo da margarina, onde a Unilever tinha 70% do mercado em 1997 e mesmo assim a divisão dela não durou 20 anos, pois perdeu espaço para o azeite e a manteiga. E mesmo no final da divisão da margarina dentro da empresa, a empresa continuou sendo líder de mercado desse produto.

Exemplo que não está no livro. A Netflix considera que jogos são um concorrente tão grande quanto streaming, e ano que vem vão entrar nesse mercado.

2019
https://www.uol.com.br/start/ultimas-noticias/2019/01/18/como-assim-para-a-netflix-fortnite-e-seu-principal-concorrente.htm

2021
https://www.terra.com.br/gameon/netflix-confirma-que-vai-adicionar-jogos-a-assinatura-sem-custo-adicional,2b0e30deb7138e9367619df764987e40voijx80m.html

A definição de “job”

A chave principal para entender a teoria é a que os consumidores não compram um produto, eles colocam os mesmos na sua vida para fazer progresso.

Descobrir qual o progresso que o cliente quer ter ao “contratar” o produto é a chave para entender as escolhas dele.

O segundo fator principal é a circunstância, pois sem interpretar a circunstância que o cliente tomou uma decisão, não conseguimos entender o progresso que ele quer fazer.

E por último, compreender a complexidade emocional e social do cliente.

Entender essas três dimensões proporciona o “job to be done”.

Mais importante do “quem” ou “o que” é “o porque”.

Onde procurar os "job to be done"?

Na sua própria vida

Vários negócios começam por dores dos próprios criadores, e entender a fundo essas dores pode ser um caminho.

Competindo contra o nada

Muitas vezes seu maior competidor é não fazer nada. No livro o autor da exemplo de uma universidade EAD que viu que muitos adultos americanos preferiam ficar em casa sem fazer nada do que estudar, e foram atrás para entender o motivo. Com isso, criaram uma das maiores universidades americanas de EAD.

Gambiarras

Identificar onde os consumidores estão usando um produto com a função de A para realizar porcamente a função de B, por não ter nenhuma alternativa melhor.

A empresa Intuit percebeu que as pessoas usavam o software de gestão de gastos pessoais dela para gerir a conta de pequenas empresas, ao invés de usar softwares completos de contabilidade por acharem complexo demais.

Ao perceber isso criaram o quickbook, o produto que mais cresce na empresa.

Buscar por coisas que as pessoas não querem fazer

Descobrir atividades que as pessoas tem que fazer mas não querem.
Acho que o V360 se aplica aqui.

Casos não usuais

Entender porque certos consumidores usam seu produto de uma maneira que não deveria ser usada.

Confesso que achei repetido com o caso 3.

Após identificar o “job to be done” usando uma das técnicas acima, é necessário entender o contexto social, econômico e emocional.

Existem dois momentos onde o consumidor contrata um produto: o “Big Hire”, que é exatamente o momento em que ele paga, e o “Little Hire”, quando o cliente usa o produto.

Medir os dois momentos é de extrema importância

Existem quatro forças que competem entre si na hora do consumidor contratar um produto.

Duas levam o consumidor a contratar algo:

O tamanho do problema
O quão boa é a solução

Outras duas levam o consumidor a ficar com o que já conhece:

A inércia da mudança
A ansiedade da mudança

Muitas empresas focam na primeira lista, melhorando seus produtos e identificando grandes dores, quando deveriam também tentar reduzir o impacto da segunda.

Somente quando a soma das duas primeiras forças se sobressai muito a soma da segunda, que a contratação do produto ocorre.

Consumidores não são bons em dizer o que eles realmente querem, mas podem dizer quais são suas dores.

Para conseguir cobrar um valor acima do mercado você precisa entender o “job to be done”, criar uma experiência única e incorporar essa experiência em todo o seu processo.

O exemplo do livro é a Ikea, uma loja de móveis.

Nessa loja, os móveis são pensados para serem montados pelo próprio consumidor, de uma forma que cabe em qualquer carro e com uma única ferramenta que já vem no pacote. Além disso, a Ikea possui um lugar para as crianças ficarem brincando e um café para o cliente se recompensar “pelo dia chato de comprar móveis”.

O produto da Ikea é fácil de copiar, mas toda a experiência não é.

Os processos da sua empresa devem ter o "job to be done" como centro.

As melhorias de processo tem que acontecer para você ficar mais eficiente em resolver o “job to be done”, pois não adianta ficar mais eficiente em fazer a coisa errada.

A falácia que as empresas acabam caindo com o crescimento:

A falácia dos dados operacionais

As empresas acreditam que é possível migrar de análises de poucos casos a fundo quando são pequenas, para análise de muitos casos usando estatística quando são grandes._

Dados só são úteis se a empresa realmente entender o contexto por trás dos mesmos.

Pois no geral, a empresa tem os dados de quantas furadeiras vendeu, mas não de quantos buracos o cliente fez com elas.

A falácia do crescimento dentro da própria base

Esse é um ponto que me fez refletir bastante. Confesso que não sei se tenho total conhecimento, mesmo relendo essa parte algumas vezes.

O autor argumenta que muitas empresas buscam aumentar receita vendendo outros produtos para o mesmo cliente, mas que isso faz com que ela perca a visão de “job to be done” que a levou até ali.

Um exemplo do próprio New York Times, que tenta atacar vários “job to be done” com informações muito ricas em conteúdo e ao mesmo tempo ser um jornal para passar o tempo. E com isso perde espaço para jornais de metrô que são de graça e para jornais especializados que são mais caros que ele, como o The Economist.

A falácia dos dados de confirmação

Se você está procurando confirmar um ponto de vista nos dados, eles vão dizer o que você quer ouvir.

Resumo: Creative Selection

Izaias Miguel — Mon, 21 Mar 2022 13:27:06 +0000

Esse livro estava em minha estante há uns 2 anos e ainda não tinha conseguido priorizar. Finalmente consegui ler e achei bem interessante, com alguns pontos a compartilhar.

O livro basicamente conta algumas estórias bem bacanas dos bastidores da criação de novos produtos pela Apple. O autor foi engenheiro de software lá entre 2001 e 2017, passando ainda pelo AirBnB depois disso.

Por ter sido escrito por alguém que trabalhou no código de alguns dos principais produtos da Apple no período, o livro traz uma visão mais técnica que me chamou bastante atenção (dada minha formação em Ciência da Computação). Tem até um trecho de código em C++, rs.

O autor, Ken Kocienda, foi um dos responsáveis pela criação do Safari, do envio e visualização de e-mails em HTML pelo Mail, e pela criação do teclado do iPhone (e mais tarde do iPad). Portanto, produtos essenciais no ecossistema da Apple.

O Safari foi lançado em 2003 apenas - antes dele, poucas pessoas se lembram, mas o browser do Mac era o Internet Explorer da Microsoft. O teclado era um dos principais riscos para o lançamento do iPhone, pois uma das principais inovações à época era justamente ser um telefone sem teclado, concorrendo com o famoso teclado do Blackberry (além do fato de que o input de dados era um dos principais traumas da Apple em dispositivos móveis, dado que tinha sido um dos principais fatores de insucesso do Newton na década de 90).

Em resumo, o autor cita como principais fatores de sucesso na criação dos produtos da Apple: a cultura da empresa, a estrutura dos times e o processo de inovação.

Sobre a cultura, ele cita sete elementos essenciais para o sucesso dos softwares da Apple, dando exemplos desses pontos ao longo das estórias, que conta:

Inspiração: pensar em grandes ideias e imaginar o que poderia ser possível
Colaboração: trabalhar em conjunto com outras pessoas e buscar combinar suas forças complementares
Habilidades (craft): aplicar habilidades para atingir resultados de alta qualidade e sempre tentar fazer melhor
Diligência: fazer o trabalho chato necessário e nunca recorrer a atalhos ou meias medidas
Agilidade na tomada e decisão (decisiveness): fazer escolhas difíceis e se recusar a atrasar ou procrastinar
Gosto (taste): desenvolver um senso refinado de julgamento e achar o equilíbrio que produz um todo prazeroso e integrado
Empatia: tentar ver o mundo na perspectiva de outras pessoas e criar um trabalho que se encaixe em suas vidas e se adapte à suas necessidades

Esses princípios não estavam escritos em lugar nenhum, nem eram passados aos recém-contratados. Mas, fluíam do trabalho tanto top down, a partir da liderança do Steve Jobs, quanto bottom-up, a partir dos engenheiros.

Sobre a estrutura dos times, o autor reforça que sempre eram times muito pequenos, onde os próprios engenheiros eram responsáveis pelo produto, da ideação à codificação - não havia um “product manager”.

Apenas 10 pessoas trabalharam no Safari e apenas 25 foram responsáveis por todas as patentes do iPhone. Eles quebravam o software em diversas pequenas partes que se falavam muito pouco. Por exemplo, o Ken como responsável pelo teclado do iPhone, não sabia absolutamente nada sobre o que estava sendo feito em termos de hardware, só trabalhava com um protótipo da tela conectado a um computador.

Em relação aos demais softwares do iPhone, a interação de Ken era basicamente fazer com que as pessoas que criavam aplicativos, como Notas e E-mail, usassem o teclado e dessem feedbacks ao longo do uso. Além da compartimentalização em pequenos times, a Apple ainda tinha uma preocupação muito grande com o sigilo, de forma que poucas pessoas tinham acesso ao todo.

O processo de desenvolvimento é a principal ênfase do livro. O autor cita o processo que ele denominou de “Seleção Criativa”, é basicamente a criação rápida de protótipos que são validados pela alta liderança da empresa, e em alguns momentos pelo próprio Steve Jobs. Esses protótipos são sempre funcionais - eles não “perdem tempo” criando documentos ou protótipos não funcionais, pois segundo ele é muito difícil provar a viabilidade e usabilidade de algo que as pessoas não estão usando.

Esse ciclo de criação rápida de protótipos funcionais, feedback pela alta liderança e ajustes no protótipo com base nos feedbacks, permite que o time fique focado em entregar código tendo retornos muito rápidos e foque no que é importante para o usuário, o que casa muito com os princípios de agilidade.

Ken cita ainda a diferença dessa abordagem para a de empresas como o Google, que foca muito em fazer testes A/B para tudo e em lançar produtos não tão maduros ainda para receber feedback dos usuários. Na Apple, os próprios times são responsáveis pela tomada de decisão, dado que a cultura é de lançar produtos já maduros e que praticamente não foram testados com usuários “reais” pelo sigilo que a empresa impõe. Essa diferença é muito ressaltada pelos aspectos culturais de decisiveness e taste, onde os próprios engenheiros tomam decisões o tempo todo pelos usuários da Apple.

O autor ainda dá ênfase às demonstrações de produtos para Steve Jobs. Nessas demonstrações ele sempre estava com a atenção totalmente focada e pedia a opinião do apresentador sobre o que ele achava de algo (ex: retirar um dos dois templates de teclado do iPad). Steve sempre prezava pela simplicidade que ajudava o usuário a usar e retirava toneladas de complexidade do desenvolvimento. Quando pedia a opinião, era para ensinar as pessoas a pensarem sobre o produto com a mesma cabeça que ele, em vez de só dizer como deveria ser.

Eram muitas demos, então ele prezava por comunicação direta e concisa, sem rodeios. Além disso, ele sempre dava um foco único para o time - no caso do Safari por exemplo, ele queria que o browser fosse muito mais rápido que os demais, o que fez com que o time focasse totalmente em não adicionar nada que aumentasse o tempo de resposta e trabalhasse arduamente para remover todos os gargalos.

Em qualquer atividade complexa, comunicar uma visão bem articulada para o que você está tentando fazer é o ponto inicial para descobrir como fazer. Embora criar essa visão seja difícil, é muito mais difícil completar todo o circuito: ter uma ideia, um plano para realizá-la e executar o plano com altos padrões, tudo sem se atolar ou mudar a direção.

Ter um único objetivo para ser excelente é muito importante para atingir a excelência. Quando foi lançado, o Safari era 3x mais rápido que os demais browsers.

*Conclusão *

Achei muito legal tanto para conhecer mais a estória de alguns dos produtos mais icônicos da Apple (depois disso não consigo mais digitar no teclado do iPhone sem pensar de forma um pouco mais profunda sobre o que está por trás) quanto por conhecer o interior da Apple. Para mim, ela sempre foi uma das maiores caixas pretas em termos de estrutura e processo de inovação. Vale muito a leitura para quem se interessa pelo tema.

Resumo: Creative Selection

leticiacruzz — Mon, 21 Mar 2022 13:23:50 +0000

Esse livro estava em minha estante há uns 2 anos e ainda não tinha conseguido priorizar. Finalmente consegui ler e achei bem interessante, com alguns pontos a compartilhar.

Em resumo, o autor cita como principais fatores de sucesso na criação dos produtos da Apple: a cultura da empresa, a estrutura dos times e o processo de inovação.

Sobre a cultura, ele cita sete elementos essenciais para o sucesso dos softwares da Apple, dando exemplos desses pontos ao longo das estórias, que conta:

Inspiração: pensar em grandes ideias e imaginar o que poderia ser possível
Colaboração: trabalhar em conjunto com outras pessoas e buscar combinar suas forças complementares
Habilidades (craft): aplicar habilidades para atingir resultados de alta qualidade e sempre tentar fazer melhor
Diligência: fazer o trabalho chato necessário e nunca recorrer a atalhos ou meias medidas
Agilidade na tomada e decisão (decisiveness): fazer escolhas difíceis e se recusar a atrasar ou procrastinar
Gosto (taste): desenvolver um senso refinado de julgamento e achar o equilíbrio que produz um todo prazeroso e integrado
Empatia: tentar ver o mundo na perspectiva de outras pessoas e criar um trabalho que se encaixe em suas vidas e se adapte à suas necessidades

Ter um único objetivo para ser excelente é muito importante para atingir a excelência. Quando foi lançado, o Safari era 3x mais rápido que os demais browsers.

*Conclusão *

O livro é muito legal tanto para conhecer mais a estória de alguns dos produtos mais icônicos da Apple (depois disso não consigo mais digitar no teclado do iPhone sem pensar de forma um pouco mais profunda sobre o que está por trás) quanto para conhecer o interior da Apple. Para mim, a empresa sempre foi uma das maiores caixas pretas em termos de estrutura e processo de inovação. Vale muito a leitura para quem se interessa pelo tema.

Processo de certificação ISO/IEC 27001:2013 x V360

Diego Panaro — Thu, 03 Mar 2022 19:11:33 +0000

Você já deve ter ouvido falar em empresas certificadas ou acreditadas nas melhores práticas de mercado, não é mesmo? São as famosas empresas ISO Certified, certificadas em gestão da qualidade, ambiental, entre outras.

Mas e no quesito segurança da informação, você conhece alguma empresa certificada?

De acordo com uma recente matéria publicada na revista Exame, em fevereiro de 2022, no ano passado (2021), cerca de 26% das empresas brasileiras sofreram algum tipo de ataque cibernético, sendo: phishing, vírus e ransomware os mais comuns.

A ISO/IEC 27001:2013 oferece informações completas de como implementar um Sistema de Gestão de Segurança da Informação (SGSI). Ela tem como objetivo o atendimento de requisitos obrigatórios e processos que reduzem riscos e visam aumentar a segurança das informações da empresa. De acordo com a última pesquisa ISO, divulgada em 2020, apenas 148 empresas no Brasil possuem essa certificação.

Neste artigo falaremos um pouco sobre o processo da V360 de certificação na ISO/IEC 27001:2013, qual caminho seguimos e os desafios e motivadores nessa jornada.

Sobre a ISO/IEC 27001:2013

A ISO é a Organização Internacional para Normalização, que tem como objetivo fornecer normativas de padronização em quesitos ambientais e de qualidade, por exemplo.

Para segurança, foi criada a ISO/IEC 27001:2013 para estabelecer, implementar e manter um Sistema de Gestão de Segurança da Informação (SGSI). E o objetivo principal é o atendimento de requisitos, controles e procedimentos para garantir a segurança da informação.

Nosso processo de certificação (V360 x ISO 27001)

Agora que você já sabe um pouco mais sobre a ISO 27001, irei contar sobre o nosso processo de certificação.

Passo número 1:

Para iniciar essa caminhada, um ponto fundamental sem dúvida alguma, foi contar com a participação da alta direção. As certificações são processos custosos e irão ocupar parte do orçamento anual da empresa, e uma vez acreditada, serão necessárias auditorias internas e externas para manutenção dos certificados.

No mercado existem empresas especializadas no processo de certificação. São consultorias que irão verificar o estágio em que sua empresa está no momento e os próximos passos que deverão ser percorridos.

A próxima etapa será a elaboração de documentos e procedimentos obrigatórios de acordo com a normativa que deverá ser adquirida diretamente no site da ISO. Eles servirão como um guia durante todo o processo de certificação e auditorias.

Lembre-se, o papel aceita tudo. Empenhe-se ao máximo para que a linguagem e regras utilizadas durante todos os procedimentos sejam aderentes à sua organização.

Na V360 buscamos a simplicidade e objetividade nas documentações, o que acreditamos ter sido um diferencial para o atingimento do nosso objetivo.

Após a elaboração dos procedimentos e aprovação interna, será necessária a realização de treinamentos e capacitação do time, sendo esse um dos passos principais para obtenção e manutenção da certificação.

Todo mundo é responsável pela manutenção da segurança no dia a dia da organização. Sem o envolvimento dos times, com certeza o barco vai naufragar. A dica aqui é trazer especialistas de mercado para meetups e bate papos internos, pois com certeza ajudarão no engajamento do projeto.

Passo número 2:

Com os procedimentos divulgados e bem estruturados, chegou a hora da primeira avaliação, a auditoria interna. Algumas consultorias contam com esse tipo de serviço, o que aconteceu em nosso caso.

Por aqui, ainda não tínhamos a experiência de passar por uma auditoria, e se for o seu caso, vou te dar algumas dicas que considero essenciais. Antes, é fundamental que você compreenda que serão levantados pontos de melhoria e não conformidades, os mesmos deverão ser tratados até o início de sua auditoria certificadora para ajustes no seu SGSI.

Agora vamos as dicas:

É normal sentir aquele frio na barriga, mas mantenha-se calmo e focado;
Em caso de dúvidas sobre o que foi perguntado, peça ao auditor que seja mais claro e qual seção ele se refere, isso pode te ajudar a identificar o documento em questão;
Anote todos os pontos apresentados como não conformidades e oportunidades de melhoria;
Você pode e deve consultar seus procedimentos durante a auditoria, sempre que possível mostrando evidências que comprovem que seus documentos estão sendo utilizados no dia a dia da organização;
Por último, caso seja possível, converse com toda a equipe que será avaliada previamente, relembrando as responsabilidades de cada um.

Depois da auditoria interna finalizada é hora de verificar as não conformidades e oportunidades de melhoria apresentadas.

Baseando-se em seus procedimentos, verifique o que deve ser feito e tome as devidas providências para resolução dos problemas antes da realização da auditoria externa (certificadora ou de manutenção).

Passo número 3:

Com auditoria interna e ajustes realizados, chegou a hora da auditoria certificadora. Neste momento, diferentemente da primeira, o objetivo é ter o mínimo de não conformidades e oportunidades de melhoria possíveis.

A duração é normalmente de 1 semana, tempo em que serão percorridos todos os anexos e seções obrigatórios da normativa. Este processo deve ser realizado por uma empresa credenciada e autorizada, pois a mesma será responsável pela emissão de seu certificado.

Ao longo da auditoria será necessário o levantamento de evidências para atestar a conformidade de seus processos. Em caso de não conformidades ou oportunidades de melhoria, o auditor deverá informar um prazo limite para resolução dos pontos levantados.

Ao final, a empresa responsável poderá recomendar sua organização para a certificação, ou, poderá exigir a correção das não conformidades e oportunidades de melhoria para obtenção da certificação.

Conclusão

Mesmo se tratando de um processo trabalhoso, são inúmeras as possibilidades e facilidades a partir da obtenção da Certificação ISO 27001. A acreditação traz benefícios tanto diretos quanto indiretos para dia a dia da sua empresa, sendo alguns deles:

Maior previsibilidade de eventos e incidentes de segurança da informação, consequentemente leva à menores custos em seus tratamentos;
Credibilidade da empresa junto ao mercado consumidor, demonstrando clara e manifesta preocupação com dados e informações;
Melhoria contínua de processos, documentações e rotinas de trabalho através das constantes auditorias internas e externas

Nossa Stack

Victor Campos — Thu, 03 Feb 2022 14:28:06 +0000

Aqui na V360 gostamos de deixar nossa stack de tecnologia o mais simples possível.

Quanto menos nos preocuparmos com ela, mais tempo teremos para pensar nos nossos clientes.

Gostamos de brincar que qualquer remoção está pré-aprovada. Já para adicionar complexidade, tem que ter uma boa justificativa.

Cloud
Atualmente utilizamos a AWS para todos os serviços de infraestrutura.

Usar a AWS nos ajudou tanto em escala quanto em segurança. Saber que estamos em uma nuvem, com os certificados de segurança em dia, traz tranquilidade para nós e confiança para nossos clientes.

Banco de Dados Relacional
Usamos o Postgres como banco de dados relacional, através do serviço de RDS da AWS.

Esse sistema se mostrou estável, confiável e performático para nossa aplicação.

O que nos fez escolhê-lo, ao invés do MySQL, foi a qualidade das transações de esquema, além de algumas funcionalidades, como colunas de jsonb.

Banco de Dados Textual
Como trabalhamos com muito dado em formato de texto, adotamos uma prática de indexar os dados no ElasticSearch (também através de serviço da AWS).

Do ElasticSearch, saem hoje nossos principais relatórios e dashboards, tirando uma boa carga do Postgres.

Banco de Dados de Chave-Valor
Usamos atualmente o Redis, tanto para gerenciar jobs assíncronos (com a gema Sidekiq) quanto para o cache da aplicação.

Deixamos também a AWS gerenciar o Redis através do ElasticCache.

Framework
O framework que utilizamos para desenvolvimento da nossa aplicação web é o Ruby on Rails.

Os principais motivos dessa escolha estão descritos no post “Por que Rails?”.

De bônus, usamos o Rails Engines para separar nossas aplicações em módulos, tendo um monolito modular.

Frontend
Nosso frontend é todo construído com JavaScript vanilla.

Acreditamos que um frontend simples para o usuário não necessita de ferramentas complexas.

——

Com essa stack simples, conseguimos entregar um software de qualidade e escalável, focando no que realmente importa: o cliente final.

GitHub como Ferramenta Organizacional

Victor Campos — Thu, 20 Jan 2022 17:31:04 +0000

O nosso código dorme hoje dentro do Github e nos últimos seis meses passamos a nos organizar em volta dele.

Faz todo sentido para a gente, quanto mais próximo a empresa está do nosso código, mais fácil fica a comunicação, identificação de problemas e oportunidades.

——

Repositório de código
Começamos a usar o Github como todos começam, usando para guardar o nosso código.

Além dele, fizemos fork de algumas gemas que tivemos que fazer alguma modificação para atender nosso interesse.

Essas gemas ficam em repositório aberto, enquanto nosso código permanece fechado.

Issues
Todo atendimento de Dev ocorre por meio de issues, as mesmas são divididas em melhorias, bugs ou no code.

Uma ferramenta que o Github tem, na qual nos mudou de patamar, foi a possibilidade de templates de issues. Com isso, quando qualquer pessoa da empresa quer abrir uma issue, ela já sabe os pontos importantes que precisa preencher.

O legal é que depois de um tempo toda a empresa mudou para issues. E quando alguma pessoa nova entra por exemplo, é criada uma issue de onboard.

Assim todo mundo tem visibilidade do que cada time tem de tarefa, aumentando a viabilidade.

Projects
Abandonamos o Trello e migramos todos os nosso boards para o Projects.

As issues deram visibilidade de quais tarefas existiam para cada time. No projects temos a ideia de qual etapa cada issue está no nosso processo de priorização.

Assim, evitamos a necessidade de reuniões para ficar perguntando onde cada coisa está, e podemos usar as reuniões para focar em como podemos ajudar uns aos outros a mover a issue para frente.

Actions
Também movemos todo nosso pipe de CI para dentro do Github.

Assim, o mesmo ficou integrado dentro do nosso processo, sendo executado tanto quando adicionamos uma label específica, quanto por commits.

E também, geramos os nossos relatórios de releases semanais para informar a empresa tudo que entrou no produto na semana.

Qualquer pessoa do time tem acesso, por exemplo, a deploys que funcionaram ou quebraram, testes que não passaram, etc…

Pull Request
O coração aonde o Dev faz suas tarefas. Todo pull request tem que estar vinculado a uma ou mais issues ao qual vai fechar/avançar.

Ao ser marcado como pronto para revisão, o próprio Github atribui ele para algum outro Dev revisar, não necessariamente da mesma squad.

Assim, além de melhorar a qualidade do que está sendo entregue, pois a modificação tem que ser simples para qualquer um entender, garantimos que todo o time tenha algum conhecimento de todas as partes do nosso produto.

Muitas vezes as melhores decisões de código vêm de pessoas que estão mais afastadas do problema, pois essas tendem a questionar mais as decisões tomadas.

Github CLI
Infelizmente o insight do Github é bem ruim. Mas resolvemos isso adicionando labels necessárias nas issues e um pouco de código para pegar essas informações pela api do Github.

Dessa maneira, conseguimos tirar métricas de velocidade do time, quantidade de bugs, etc.

E assim, podemos saber se as mudanças organizacionais que tomamos estão tendo efeitos positivos ou negativos.

Discussion
Essa ferramenta acabou de deixar fase beta do Github.

Ela é um fórum interno do mesmo, e usamos para registrar todas as discussões que temos internamente.

Quando algo começa a se prolongar no Discord, migramos para lá.

Até para ser fácil pessoas novas entenderem o contexto do porquê as coisas hoje são como são.

Também registramos resumo de livros que gostamos, e como resolvemos algum problema mais sério dos nossos clientes.

Wiki
Aqui mora toda a nossa documentação, desde documentação de como usar o produto, responder a certos questionamentos do cliente, até nossa boas práticas de programação.

Também usamos nossa wiki para o nosso processo de onboard. Temos documentado nela (e gosto de acreditar que cada pessoa que entra melhora esse processo) o que se espera que a pessoa saiba a cada semana até conseguir chegar em um ponto que consegue realizar as primeiras atividades sozinha.

Futuro
Quem sabe não adotamos no futuro o editor de código que o Github acabou de lançar?

O que eu posso falar é, cada dia que passa sinto menos necessidade de ter outras ferramentas de gestão de time, produto e código, além do próprio Github.

Resumo: Remote, Office Not Required

Victor Campos — Wed, 29 Dec 2021 22:35:32 +0000

Introdução

Na V360, incentivamos nosso time a se desenvolver no campo pessoal e profissional através da leitura. Como trabalhamos a distância, na ferramenta que nos comunicamos no dia a dia, separamos um canal para compartilharmos e batermos um papo sobre: livros.

Remote: Office is not Required foi um dos livros em destaque. E o tema principal dele se conecta com a empresa, pois tivemos que nos reinventar no início da pandemia em 2020, adotando o trabalho remoto.

E aqui, enxergamos que esse modelo veio para ficar. Nosso time é composto por mais de 60 pessoas espalhadas pelo Brasil, acreditamos que nós rompemos muitas barreiras e nos desenvolvemos cada vez mais, trabalhando de onde quisermos.

E por isso, resolvi trazer aqui uma resenha sobre o Remote: Office is not Required, selecionando alguns capítulos que chamaram minha atenção nesta leitura.

Resumo

Positivos:

Trabalho remoto não foi adotado antes por falta de tecnologia, mas com o avanço da internet não existe mais desculpas.

Além do mal para saúde e meio ambiente, um colaborador perde em média 400 horas se locomovendo para/do trabalho.

A hora que os colaboradores mais produzem são as horas sem interrupção. Ter uma cultura de trabalho assíncrona e com horário realmente flexível é importante para produtividade.

Trabalho remoto permite às pessoas trabalharem do lugar que mais se adeque ao seu estilo de vida.

É possível achar talento em qualquer lugar.

Trabalho remoto não é sobre reduzir custos. É sobre ter colaboradores com qualidade de vida, onde desperdiçam menos tempo com o que não importa. Além disso, o trabalho remoto também economiza dinheiro tanto da empresa com redução de custo do escritório, quanto dos colaboradores com transporte e alimentação.

Não é tudo ou nada. As empresas podem continuar tendo escritório, eles só não podem ser obrigatórios. Alguns colaboradores/funções vão continuar preferindo se reunir no escritório por motivos diversos.

Negativos:

As vezes nos sentimos perdidos sem poder estar na mesma sala dos nossos colegas para “trocar uma ideia”. Usar a tecnologia a favor, como vídeo conferência e transmissão de tela, ajuda nesse ponto.

Trabalhar fora de sincronização com seus colegas, apesar de ajudar na diminuição da interrupção, gera uma necessidade de ser mais organizado para evitar procrastinação. “Sometimes, distractions can actually serve a purpose. Like the proverbial canary in the coal mine, they warn us—when we feel ourselves regularly succumbing to them—that our work is not well defined, or our tasks are menial, or the whole project we’re engaged in is fundamentally pointless.”

Dificuldades a serem superadas

A segurança no escritório é mais controlada (até certo ponto). É completamente possível fazer políticas de segurança que se adequem ao trabalho remoto, algumas dicas:

Criptografar o disco
Travar a tela depois de 10 minutos de inativação
Sempre usar HTTPS
Colocar senhas nos celulares
Gerar uma senha diferente para cada site
Ligar autenticação de dois fatores sempre que possível

Notas do Victor: “As dicas são bem básicas e estão contidas na nossa política de segurança, mas tem outras coisas que também podemos fazer para nos deixar mais seguros. Recomendo todos relerem a nossa política de tempo em tempo e acompanhar a newsletter de segurança”.

Estar disponível para o cliente com sistema de horário flexível é um desafio, mas que se resolve com o próprio time se organizando para isso. Talvez, para colaboradores que tenham a função primária de atender o cliente, esses terão que ter um horário mais regular.

Alguns trabalhos não podem ser feitos remotos. Nesse caso, esses colaboradores não terão esse benefício de trabalhar remoto. Não é porque você não pode (ainda?) fazer a vida de todos melhores, que vai forçar a vida de todos serem piores. Trabalhos diferentes tem necessidades diferentes. (Assim como existem salários diferentes, bônus diferentes, etc…).

Ter as respostas de maneira mais imediata é difícil trabalhando remoto. Bom, primeiro temos que reconhecer que nem todas as perguntas são igualmente urgentes. Criar canais diferentes para cada tipo de mensagem é importante, ter um canal para mensagens que podem esperar horas para serem respondidas (deveria ser 80% das mensagens), ter um canal que pode esperar minutos para as mensagens (19% das mensagens) e ter um canal de telefone vermelho (1% das mensagens).

Como colaborar remotamente

Ter no mínimo 4 horas de overlap com o time on-line ao mesmo tempo. Parece ser o tempo ideal para facilitar comunicação, criar um sentimento de time e ainda assim ter um tempo livre sem distrações.

Use ferramentas de compartilhamento de tela para melhorar a comunicação. Ver ainda é importante.

Use ferramentas de gravar a tela para mostrar as funcionalidades que está trabalhando ou os problemas que você encontrou. Fica mais fácil entender a feature/bug vendo do que lendo uma descrição.

A agenda do time, os documentos necessários e as discussões, devem estar sempre disponíveis para os outros colaboradores do time.

Tenha seu bebedouro de água virtual, onde as pessoas podem ir para espairecer. Pode parecer um desperdício de tempo, mas na verdade é um tempo bem gasto com os colegas de trabalho.

Mantenha todos no loop. É necessário manter as pessoas bem informadas para criar um fluxo de informações dentro da empresa, gerando a sensação de que estamos todos no mesmo barco.

Reuniões não são intrinsicamente ruins, elas são como o sal, algumas pitadas deixam o prato melhor, mas estraga a comida e a saúde se usada de mais. A maioria dos problemas deveria conseguir ser resolvido sem uma reunião. E lembre-se, não existe isso de reunião de 1 hora. Se você está em uma reunião de 1 hora com 5 pessoas, são 5 horas investidas naquela reunião. O problema tem que valer esse investimento.

Sobre gerenciamento, ele continua sendo importante. Porém, para funcionar bem no trabalho remoto é necessário que o time mantenha os status atualizados e o gerente acredite neles, para não precisar interromper as pessoas perguntando como as coisas estão indo.

O isolamento é um problema no trabalho remoto. Por mais que a comunicação flua bem através dos canais digitais, as pessoas ainda precisam de pessoas reais. Um aprendizado do livro é que essas interações com pessoas reais não precisam vir de colegas de trabalho, pode ser seu cônjuge, filho(a), vizinhos e amigos, passe o tempo extra ganho no trânsito com eles.

Se você contratou pessoas que gostam do trabalho que fazem, é mais provável que elas trabalhem mais remoto do que menos, esticando o dia de trabalho para 10~12 horas. É necessário dobrar a atenção com burnouts, e a melhor forma de fazer isso é criar a cultura de expectativas razoáveis.

Incentive os colaboradores a se movimentarem e serem saudáveis. A saúde deles é muito importante para a empresa.

Com os clientes, é importante gerar confiança desde o início e deixar claro que o trabalho é remoto. Além disso, é preciso redobrar a atenção nas respostas com eles, responder e-mails, mensagens e retornar telefonemas se tornam primordiais. A distância causa ansiedade e temos que manter o contato para diminuir a mesma. E por último, mostre o progresso, quanto mais progresso a ser mostrado, melhor.

Trabalhar remotamente permite às pessoas se mudarem e continuarem na empresa.

Contratação:

Habilidades sociais são mais importantes remotamente do que socialmente. Principalmente a habilidade de escrever.

Desafios com casos reais são melhores do que desafios inventados para medir o fit com a empresa. Se está contratando um desenvolvedor, olhe código. Se está contratando alguém de Customer Success, olhe como essa pessoa responde dúvidas reais de clientes.

Pague salários iguais independente da onde a pessoa for. Pode parecer tentador pagar salários menores para quem vive um custo de vida menor, mas se você tem condições de pagar salários melhores do que os salários locais de onde a pessoa mora, use isso para contratar os melhores daquele lugar, não brigar pelos medianos (aqui no sentido de estar na mediana mesmo).

Procure duas qualidades em novos colaboradores: Inteligência e “Gets things Done”.

Como já dito, a habilidade de escrever bem é primordial. Como a maioria dos argumentos e comunicação vão ser de forma escrita, escrever bem é um must have.

Tenha um teste prático no processo seletivo, nunca avalie um candidato só pelo currículo.

No fim, avalie a cultura. Você espera o resultado, mas convive com a pessoa, mesmo remotamente.

Gerenciando trabalho remoto

Não gerencie horário de trabalho, gerencie as entregas. Colocar as pessoas certas para fazer as coisas certas, dividir corretamente o trabalho, ajudar a superar problemas, etc. Esse deveria ser a forma correta de gerenciar o trabalho.

Se reúna presencialmente 2 vezes por ano pelo menos.

Aprenda com o gerenciamento de open source: projetos open source batem de frente com grandes empresas, com colaboração remota e assíncrona. Aprender com eles é fundamental. Algumas das suas características são: “Motivação intrínseca”, “Informações abertas”, “Encontros casuais ao vivo”.

Mantenha um ambiente em que não diferencie profissionais que trabalham remoto dos que trabalham presencial.

Faça reuniões de 1:1 frequentemente, uma vez a cada poucos meses pelo menos.

Remova empecilhos, trabalhar assíncrono significa que nem sempre você vai poder contar com a pessoa na hora que você precisa. Por isso, quanto menos você precisar melhor.

Empodere as pessoas e crie um ambiente de confiança para que elas consigam tomar as decisões sem terem medo.

Ter cuidado com a sobrecarga mais do que com a carga de menos trabalho. Se você contratou correto é um problema muito mais provável de ocorrer. Lembre-se que você está em uma maratona, não em uma sprint.

Use a escassez a seu favor. Como conversas cara a cara (video chat) vão ser menos frequentes, elas vão ter mais valor. Use ela para passar os recados mais importantes.

O dia a dia de um trabalhador remoto

Crie uma rotina, é muito fácil se perder nas horas trabalhando remoto e não conseguir separar trabalho do dia a dia. Ter as suas roupas de trabalho e roupas de não trabalho, pois mudar de roupa ajuda você também a delimitar quando está trabalhando. E se possível, tenha um local para trabalho separado e/ou delimite locais onde o trabalho é proibido (dica, seu quarto).

Trabalho remoto não precisa ser tudo ou nada, você pode passar alguns dias no escritório e alguns dias em casa, ou mesmo parte do dia em casa e parte do dia no escritório. Trabalho remoto é sobre flexibilidade.

Tenha um computador separado para trabalhar do seu computador para diversão.

Se ajudar, busque um local de trabalho perto da sua casa, um coffee shop ou um coworking.

Seja sincero sobre o que está tirando sua motivação. Motivação é algo que vem de dentro, dificilmente as outras pessoas da equipe vão saber os motivos da sua falta de motivação do que você mesmo. Se expressar é importante para resolver o problema.

Se permita trabalhar em viagens (não durante as férias), mas use a liberdade do trabalho remoto para conhecer lugares novos.

Passe tempo com sua família.

Por que Rails?

Victor Campos — Thu, 16 Dec 2021 13:50:56 +0000

Introdução

As primeiras linhas de código do V360 foram escritas em 2016. Mas se fôssemos reescrevê-lo hoje, em 2021, ainda usaríamos Ruby On Rails?

A resposta é sim!
E o objetivo desse post é dizer o porquê.

———

Comunidade

O Ruby On Rails nasceu em 2003 e, 18 anos depois, a sua comunidade continua forte. Empresas maduras como Github, Gitlab, Shopify, Basecamp e Stripe (segunda startup mais valiosa do mundo, continuam utilizando-o.

De um tempo para cá, iniciou-se um movimento dessas empresas de atualização do framework e suas gemas para a última versão, trazendo uma gigantesca força financeira e de pessoas para o desenvolvimento do framework.

Github: https://github.blog/2020-08-25-upgrading-github-to-ruby-2-7/

Gitlab: https://about.gitlab.com/blog/2020/07/08/migrating-to-puma-on-gitlab/

Shopify: https://shopify.engineering/upgrading-shopify-to-rails-5-0

E não apenas empresas grandes e consolidadas, como essas já citadas, usam o Rails. Novas startups - como Linkana, Beep Saúde, Donorbox, Dev.to e outras mais - trazem inovação para o ecossistema.

Essa mistura de estabilidade e inovação faz o ecossistema Rails caminhar numa direção correta.

Times Pequenos

Uma startup não tem dinheiro, nem no início, nem nos primeiros anos.

Além disso, a escassez de talentos no mercado está cada vez mais visível, seja para empresas grandes, seja para startups. Em qualquer linguagem.

Então, ter uma tecnologia como o Rails, que é otimizada para times pequenos, é fundamental.

A arquitetura de "citadel" (explicada neste ótimo artigo da Appsignal - outra startup em Rails), permite que poucos desenvolvedores façam o trabalho de muitos.

Evita decisões desnecessárias

Muitas das nossas decisões técnicas, no fim do dia, não geram valor algum para o cliente.

O Rails busca tomar exatamente essas decisões por você, fazendo com que consiga focar naquilo que realmente importa para seu usuário final.

Ao seguir as famosas convenções do Rails, você evita tomar dezenas (ou centenas?) de micro decisões, e as coisas simplesmente funcionam como "mágica".

Respira a Web

O Rails nunca tentou brigar com a Web. Muito pelo contrário, ele busca se intrometer somente onde é realmente necessário.

Um exemplo disso é a decisão de remover o Webpacker como padrão no Rails 7. A web já chegou no nível de não precisar mais dele.

E qual a beleza nisso? A beleza é que a própria web já é uma das maiores criações da humanidade. Diferente de uma aplicação desktop, um site web escrito no dia 1 continua funcionando até hoje.

Ela tem defeitos, é óbvio. Mas no geral, as soluções para esses defeitos que tentaram sobrescrever a web ficaram para trás, como Flash e Java applets, por exemplo.

Até mesmo a tentativa do virtual dom, do React/Angular, já está começando a ser questionada. Basta ver o crescimento do Svelte na comunidade JavaScript.

O Rails, em 2003, percebeu que a melhor maneira era abraçar a web como ela é, e atuar somente no necessário e enquanto necessário.

Rails Escala

Apesar de toda a brincadeira do "Rails não escala", a verdade é que ao longo do tempo ele se mostrou bem escalável.

// Detect dark theme var iframe = document.getElementById('tweet-1404835709278580739-373'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1404835709278580739&theme=dark" }

// Detect dark theme var iframe = document.getElementById('tweet-885664106677710850-908'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=885664106677710850&theme=dark" }

Assim, estamos confiantes de que conseguiremos crescer ainda MUITO e por muito tempo usando Ruby On Rails.

——

Poderíamos citar vários outros motivos que nos levariam a escolhê-lo novamente, mas aí o post se estenderia demais! :)

Se você quiser saber um pouco mais sobre o assunto ou ficou com alguma curiosidade, deixe aí nos comentários.

Obrigado, e esperamos que a leitura tenha valido a pena!