Each host branch with capistrano
I think many people are familiar with the notion of “struggle for staging”, when all the developers at the same time the day before the release want to share their achievements so that the tester checks them as soon as possible and does not have to edit bugs all night , right? Who is interested to see how we solve this problem for RoR-projects with the help of Capistrano? I ask under cat.
Every new ticket we make in a separate thread, as advised by this git-flow . We use JIRA as the task manager / bug tracker, so the ticket number in JIRA = branch name. We use Jenkins CI not at full capacity, so far only for deploying code on the staging development version after merge into it for integration testing.
I wanted to be able to check each ticket in isolation, and take only verified tickets to the release, and leave those that contain bugs to the next.
')
Considered various options from sharinga working machine using ngrok to SaaS like teatro . The first option turned out to be inconvenient, and the second one was dropped because not all projects have the opportunity to send to a third party. Therefore, since all our RoR projects are deployed using capistrano, it was decided to write a small extension that will deploy the project from a specific branch to its host (for example, jira-123.example.com ).
In short, the development process looks like this: after running the ticket, the developer pours it onto the demo host, after checking the tester creates a merge request, after closing which Jenkins pours a future release on staging.
All that the developer does during development is pouring code, rolling in migrations and starting third-party services (sidekiq, resque, etc.).
This plugin has a number of limitations, the most important thing is that it works only for RoR projects, and only with git.
This plugin has only three commands:
To create a demo host you just need to type cap staging demo: create from the working directory and that's it. By default, you will be prompted to cast the current branch.
At the moment, the biggest problem is a long assembly of assets, you need to force it not to recompile everything, but only differential. And also, someone's migration can break other people's hosts, so at staging we keep a clean base, in such a case. There were attempts to make a separate database for each branch, but then you had to create either an empty database or copy it. The first option is bad because you would have to fill in content for testing, and the second one does not have a universal means for copying data for several DBMS, but in the future we plan to make adapters for SqlLite, MySql and Postgres.
We laid out our developments in open access , so everyone can read and use, pull requests are welcome.
PS: I am ready to answer your questions in the comments, listen to alternative solutions and constructive criticism.
Little about tools
Every new ticket we make in a separate thread, as advised by this git-flow . We use JIRA as the task manager / bug tracker, so the ticket number in JIRA = branch name. We use Jenkins CI not at full capacity, so far only for deploying code on the staging development version after merge into it for integration testing.
The essence of the problem
I wanted to be able to check each ticket in isolation, and take only verified tickets to the release, and leave those that contain bugs to the next.
')
What other than Capistrano?
Considered various options from sharinga working machine using ngrok to SaaS like teatro . The first option turned out to be inconvenient, and the second one was dropped because not all projects have the opportunity to send to a third party. Therefore, since all our RoR projects are deployed using capistrano, it was decided to write a small extension that will deploy the project from a specific branch to its host (for example, jira-123.example.com ).
Process
In short, the development process looks like this: after running the ticket, the developer pours it onto the demo host, after checking the tester creates a merge request, after closing which Jenkins pours a future release on staging.
What makes capistrano-demo
All that the developer does during development is pouring code, rolling in migrations and starting third-party services (sidekiq, resque, etc.).
This plugin has a number of limitations, the most important thing is that it works only for RoR projects, and only with git.
Configuration
# , , # set :demo_db, -> { demo_default_db } # , - set :demo_host, -> { fetch(:application) } # . # , unicorn, nginx sidekiq: # invoke 'unicorn:restart' # invoke 'sidekiq:restart' # execute :sudo, :service, 'nginx restart' # execute :rake, 'cache:clear' set :demo_restart_cmd, -> { raise 'You must specify "demo_restart_cmd" proc' } # , , # : # File.expand_path("../../../../config/stages/#{fetch(:stage)}/templates", __FILE__) set :demo_templates_dir, nil # , , .erb # : # set :demo_templates_entries, [ # {template: '/nginx.conf.erb', file: demo_path.join('config', 'nginx.conf')}, # {template: '/database.yml.erb', file: demo_path.join('config', 'database.yml')}, # {template: '/unicorn.rb.erb', file: demo_path.join('config', 'unicorn.rb')}, # {template: '/settings.local.yml.erb', file: demo_path.join('config', 'settings.local.yml')}] set :demo_templates_entries, [] How to use
This plugin has only three commands:
- demo: create - create / update demo host
- demo: restart - reboot
- demo: destroy - Stop processes (configured using before / after) and delete directories.
To create a demo host you just need to type cap staging demo: create from the working directory and that's it. By default, you will be prompted to cast the current branch.
Conclusion
At the moment, the biggest problem is a long assembly of assets, you need to force it not to recompile everything, but only differential. And also, someone's migration can break other people's hosts, so at staging we keep a clean base, in such a case. There were attempts to make a separate database for each branch, but then you had to create either an empty database or copy it. The first option is bad because you would have to fill in content for testing, and the second one does not have a universal means for copying data for several DBMS, but in the future we plan to make adapters for SqlLite, MySql and Postgres.
We laid out our developments in open access , so everyone can read and use, pull requests are welcome.
PS: I am ready to answer your questions in the comments, listen to alternative solutions and constructive criticism.
Source: https://habr.com/ru/post/264105/
All Articles