How to build a Ruby On Rails website pipeline? Is RoR suitable at all?

Question

Ruby on Rails

There is a company A that develops websites for design studio B.
This is for you to understand 10-20 expensive websites for large companies, but simple in essence. Only the effective frontend is difficult.
Previously, the company had a good, universal, self-written CMS in PHP and the new project was simply uploaded to FTP. Everything is hopelessly outdated and people are fed up with PHP. Well, in general, the processes were so-so.
Now there is an idea to significantly improve the stack, completely separate back-end development from the front and switch to Rails (I have been writing on rails for 4 years), and therefore the question is: how to build a pipeline that is close in its simplicity with the following requirements:

• developers do not spend time creating a new project and deploying changes (or almost none)
  
• cheap servers or services (now a php server costs a penny, we don’t consider highloads - they don’t exist)
  
• it would be nice if the services of a devops were not required, but not critical. Albeit very rarely.
  

I see myself some kind of Digital Ocean, Travis, Github and Docker. But it's pindets how difficult it is for beginners. Is there any other way to ask?
An important sub-question: are there any better alternatives? Node.js?

Answer 1

I set up a pipeline for a completely similar company a couple of years ago. The only difference is that there was almost no PHP legacy.
I took the Django stack as a basis, because it was a great fit for the number of freelancers on the market and the fact that in Django "there is always one obvious way to do something right", while in Node there are a lot of these paths and every new programmer hired has to slightly, but change his development approaches.
At first, the main emphasis had to be made on DevOps, everything worked on GitLab, GitLab CI, Docker and Flops.ru hosting. This is a very dreary, long work on the initial setup of everything and everything. Not sure if it can be avoided.
The development of the project was carried out as follows:
1) There is a repository with a "blank", copied to a new repository.
2) GitLab CI is connected, the entire configuration is set in the environment variables. For example, on which servers to run, on which domains, and so on.
3) Programmers go for a walk through other repositories in search of successful technical solutions in similar projects.
4) They push the code, it is uploaded to servers. Each branch is assigned to its own subdomain, features are tested separately. Codereview, Unittests, Merge Requests - it all really helps.
As a result, when everything started up and started to help, and not hurt (about half a year later), another problem arose - how can we build the same thing on the frontend? And that's a completely different story...

Answer 2

So, let's separate the flies from the cutlets.
I see two issues here:
Moreover, the second depends on the first, so it is necessary to solve in the same sequence.
So,
1: There are three choices:
The choice here is based on your wallet (the lower - the more expensive) and knowledge (the lower - the easier).
2: It's time to deploy.
If you have PaaS, then the issue of deployment is well covered in their instructions - and each to his own.
If you have a server, then it is better to deploy with docker (or rather docker compose). This is done in the following way. First, break your service into maximally atomic micro-services.
For example, you got: the application itself (RoR + sidekiq), PostgreSQL, Redis.
Accordingly, you make three containers. You describe all three containers in the docker-compose.yml file
But there is one thing here. While you can take standard PostgreSQL and Redis - and these containers are already ready, then you need to finish your RoR every time. After all, dependencies or something else could change in it. Therefore, in docker-compose.yml you describe one of the containers with the word "build ." - this means that docker compose will not try to pull it from the Internet, but will find the Dockerfile file and, according to it, build the image on its own. And already in this image there will be something like:

# Please keep same version as in Gemfile (https://hub.docker.com/r/library/ruby/)
FROM ruby:2.3.4

ENV RACK_ENV development

COPY . /usr/share/website

WORKDIR /usr/share/website
RUN bundle install

CMD ["/usr/share/website/run_rails.sh", "/usr/share/website"]

The file run_rails.sh will have something like:

#!/bin/bash

cd $( cd "$( dirname "${BASH_SOURCE[0]}" )" && pwd )
export RACK_ENV=development
export SECRET_KEY_BASE=266a11dc19acc67107064dfddcecb4187545a08b35bd9a847c7b53545be22dbd8d115036024fcfc659f5936ba4a5df9a7d2a937797fv9d7v9fv7v97e9f430ff

bundle install

bundle exec rake db:migrate db:seed
bundle exec rake assets:precompile

find /usr/local/bundle -name guard
bundle exec foreman start --procfile Procfile.dev --port 8080

And the docker-compose.yml itself will look like:

version: '3'

services:
    pg:
        image: postgres:9.6
        environment:
            - PGDATA=/var/lib/postgresql/data
            - POSTGRES_DB=project_db_dev
            - POSTGRES_USER=project_user
            - POSTGRES_PASSWORD=project_password
        volumes:
            - ${PG_DATA_DIR}:/var/lib/postgresql
        ports:
            - 5432:5432

    rd:
        image: redis:4.0
        ports:
            - 6379:6379

    ws:
        build: .
        volumes:
            - .:/usr/share/website
        ports:
            - 8080:8080
        depends_on:
            - pg
            - rd

Please note that the PostgreSQL data is not on the image itself - otherwise it can be lost when updating or removing the server.
That's your whole problem.

Answer 3

You can deploy using capistrano, deploy ansible servers

Answer 4

I noticed that when starting a new RoR project, there are a number of routine actions that can be automated.
For example
- Connect a database
- Connect Capistrano
- Connect all sorts of utility gems like Nokogiri, Russian, Paperclip, Sorcery
- Connect front libraries
You can write a simple script - application generator, which will create a new application immediately with libraries (and maybe even controllers and typical routes) accepted in your company
Now I'm thinking about this for React Native applications