How to properly deploy a project?

Question

Software Deployment

Laravel is used as an api for the front and the application
.
(on the server)
As it seems to me now:
1) I do git commit -> push // so that there is some kind
of versioning and you can return did not understand how. Is there any standard instruction?
2) Laravel has such a thing as migrations. I figured out how to work with them, but I don’t understand how they will work when there are some updates.
If I create some other migrations on the local, how can I transfer them to the server?
Besides if to use git? After all, the git will not be able to "produce" the migration?
3) How to save passwords?
Right now everything is stored in .env . And now my database is hosted, not locally. How can I make it so that I connect to one database on a local computer, and on the hosting Laravel already connects to another?

Answer 1

Apart from modern docker-based approaches, the most versatile way is to use ansible and its module docs.ansible.com/ansible/latest/deploy_helper_modu...
If you google 'laravel deploy ansible' you will find many articles and repositories on github, from which you can get all the necessary information.
ps And never use bash scripts for such tasks.

Answer 2

according to paragraph 1 - it is done through the GIT web hook
according to paragraph 2 - migrations, like any other project files, are transferred via GIT to the production server
, but in order to apply them, you need to roll them on the production
. p3 - passwords are set individually on the server, they cannot be pushed into GIT
You can use full-fledged deployment tools:
Deployer
Capistrano

Answer 3

There is a free and good tool (there are ready-made basic settings for various frameworks, including Laravel): Deployer - Deployment tool for PHP .
And there is a paid service, also good (but expensive for me): Envoyer .

Answer 4

1) Deployment initiator: this can be either a git hook or a manually called command. To begin with, I recommend not to get hung up on hooks, but to call them manually. If you deploy not so often, then this will be quite enough and more secure.
2) migrations are just sql commands that change the database. Running migrations is the same if you manually run any sql client on your computer, join the database and start adding/removing tables and columns. My point is that migrating to a prod server can also be done from a local machine if the migrations are done with a production configuration.
3) Configuration. In the case of a .env file, this can be done in the following way:
- create a .env.dist file in which we specify all the variables that are required for the application, but leave the values ​​​​empty
- commit .env.dist to the repository. Now we have a template in the repository according to which we can create an .env file on the local machine and fill in the values ​​of the variables
- add .env to .gitignore (if .env was already comical, then we must first delete it and commit the deletion, otherwise .gitignore will be it's wrong to ignore .env)
- now that .env is being ignored by git, we can copy our .env.dist template as .env and fill in the variable values. Anyone who installs this project from scratch on their machine will have to do the same.
In general, a deployment can be divided into several stages:
- deployment initiator (any event on which the deployment starts)
- building the project (preparing all files in the state in which they should be sent to the prod server and replacing the current files on the server)
- testing the project (running unit and functional tests to make sure that we upload the working code)
- actually transferring the project to the server
- execution of post-deployment commands that should be executed when new files are already on the server (for example, migrations, etc.)
- integration smoke tests (you can send GET requests to the key pages of our prod server and check that the responses contain the expected text or HTML, this is done purely to make sure that after the deployment the server is still alive and displays the necessary pages)
All these steps can be done manually, or you can automate (up to full automation), but I do not recommend automating everything at once - it is better to add automation carefully step by step so as not to break firewood.
There are many tools available to automate builds and deployments. Most of them simply offer an extra layer of abstraction over low-level commands, which makes it easier to organize builds of large projects with many steps and think less about the details. Usually, developers use for any projects any one tool with which they are on "you" - it's always convenient, you don't have to learn anything new, all the bumps are already stuffed, all the rake has come. If the developer has no experience with such tools and the project is quite simple, then I would recommend starting by writing a simple script in any convenient programming language. In this case, you do not have to spend time learning a new framework and you will have maximum control over the process in your hands.
I have no experience with laravel, but for a symphony project, I would write something like this bash script:

# если Вы деплоите с локальной машины,
# то как минимум не стоит собирать проект из файлов с которыми Вы работаете в редакторе,
# потому что там у нас могут быть незакомиченые изменения, локальные настройки
# и еще много чего, что не должно попасть на prod сервер
# поэтому проект будем собирать с нуля в отдельной директории, например "build"
# (которую тоже нужно предварительно добавить в .gitignore)

# очищаем директорию build и заходим в нее
rm -rf build
mkdir build
cd build
# клонируем наш проект
git clone [email protected]/user/project . # "." клонирует в текущую директорию
git checkout master
# создаем конфиг для prod
cp .env.dist .env
# дальше надо заполнить значения переменных в .env файле
# для начала можно просто поставить скрипт на паузу в этом моменте и заполнить вручную,
# а в будущем как нибудь автоматизировать этот процесс,
# например хранить файл с prod конфигами где нибудь на машине
# и во время сборки копировать их в проект

# устанавливаем вендоры
composer install
# прогоняем юнит и функциональные тесты, чтобы убедиться что мы не зальем какой нибудь баг
vendor/bin/phpunit -c unit.xml
vendor/bin/phpunit -c functional.xml
# прогреваем кеш
bin/console cache:clear --no-warmup --env=prod
bin/console cache:warmup --env=prod

# выполняем любые другие шаги по подготовке проекта
# ...

# теперь наш проект готов к заливке на сервер
# например через scp
scp -r . <username>@<hostname>:<destination path>

# наконец, можно накатить миграции баз данных
php app/console doctrine:migrations:migrate --env=prod

# запускаем смок-тесты которые покажут, что деплоймент прошел успешно
vendor/bin/phpunit -c smoke.xml

Answer 5

I suggest using ready-made solutions like gitlab ci. Dig towards Gitlab Runner agents and writing ci scripts. . There is the option to deploy, as well as deploy a kubernetis cluster. Gitlab is a free server with a wide range of tools, it is possible to deploy it on your own Linux server. Set up as one team.