Денис Матаков

Ко мне довольно часто обращаются родственники с просьбой помочь в настройке компьютера. Раньше мне приходилось к ним ездить, а теперь у меня есть целых две программы, которые могут помочь в этом. Удобная и условно-бесплатная для некоммерческого пользования программа TeamViewer. Хороша и удобна всем, кроме политики ценообразования. Кажется ее они взяли у корпорации Adobe, которая когда-то продавала Photoshop за нереальные деньги. Я очень надеюсь, что TeamViewer одумаются и сделают подписку для микроорганизаций на какие-нибудь 299 рублей в месяц — тогда это нужно будет обязательно купить, программа очень удобная.

Говорят, что если ей очень часто пользоваться, то она ломается и говорит, что вы, в общем, коммерческий пользователь, и вам пора платить много-много денег. Тогда на помощь приходит еще одна программа — AnyDesk. Также невероятно удобная, но в некоммерческой версии нельзя сохранять контакты, каждый раз придется заново вводить. Полноценная платная версия стоит уже 1000 рублей в месяц, для большой фирмы вполне себе позволительно. Хотя совсем не обязательно, так как бесплатная версия также работает на ура.

После того, как я получил в свое распоряжение Git, мне захотелось улучшить мое взаимодействие с самим процессом разработки и разворачивания моих проектов на новых системах. Конечно, все это можно отдать на откуп системных администраторов и разработчиков, но знать технологию всегда приятно.

Итак, Docker. Что это такое и зачем это нужно? Чтобы ваше приложение заработало на вашем локальном сервере, вы устанавливаете огромное количество разных приложений, например, интерпретаторы языков программирования, системы управления базами данных, системы, запускающие скрипты по расписанию и многое другое. В процессе разработки сюда добавляется еще десяток другой разных команд и вот, в конце концов, вы получаете работающий сайт. Покупаете хостинг, заливаете файлы на сервер и… Ничего не работает. Вы забыли что-то поставить из приложений, и не можете вспомнить что именно. Или, что еще печальнее, вы установили на боевой сервер нужное приложение, но более новой версии (меня поймут разработчики на языке PHP, мажорные версии которого просто убирают некоторые критически важные старые функции).

Выход? Docker. По сути это система управления виртуальными машинами. Вы создаете свой собственный сервер в файле-образе (это как создать образ диска), в нем прописываете все что вам нужно и заливаете в облако на сайте Docker. Все, теперь этот образ можно скачать откуда угодно на любой сервер, где установлен Docker. Пара минут, и ваше приложение заработает в полную силу, даже если вы писали его под Linux, а запустили через на Mac внутри Parallel Desktop, где крутится Windows. Правда замечательная возможность?

С чего начать изучение? Как ни странно, не с видео, как я обычно рекомендую. У Docker невероятно информативная документация, где буквально за один день (как это получилось со мной) вы научитесь всем базовым концепциям. Вот что у меня получилось за пару часов ненапряжного чтения:

Да, это кит, который говорит то, что я ему прикажу. И вы можете сделать то же самое. И не спрашивайте зачем, это просто процесс обучения в стиле «и научим, и повеселим». На ките, кстати, лежат контейнеры. Так называются ваши образы, которые запущены.

Если вы хотите быть ближе к разработке и понимать, как правильно разворачивать проекты (это вам не просто получить доступ к FTP и mySQL теперь, хотя так тоже можно), обязательно изучите тему.

Как выяснилось, управление системой контроля версий очень простое. Чтобы получить необходимый минимум удобства для себя как единственного разработчика на проекте, нужно проделать совсем немного шагов. Это продолжение вчерашнего поста.

Напоминаю, наша задача: после каждой правки делать «коммит» и иметь возможность вернутся к любому коммиту в прошлом. Ну и, конечно, иметь наглядную историю доработок на проекте.

На этом этапе мы будем считать, что вы уже подключились к серверу с помощью SSH и смотрите в окно терминала. Первым делом перейдите в папку с проектом, используя команду cd (сменить директорию). Как только вы добрались до нужного пути, выполняем:

Шаг 0. Нужно рассказать Git кто мы такие. Выполняем следующие команды:

git config --global user.name "Name Surname"
git config --global user.email "example@gmail.com"

Теперь при коммите будет отображаться наше имя.

Шаг 1. Инициализируем репозиторий.

git init

Шаг 2. Рассказываем Git, что у нас есть репозиторий на GitLab (там, конечно, нужно зарегистрироваться и создать репозиторий. Это просто, подробного описания делать не буду). Это как раз то самое удобное место, откуда мы будем брать всю интересную нам информацию. Конечно, можно брать ее из командной строки, а можно немного упростить себе жизнь. Необходимая команда будет выдана самим GitLab после создания пустого проекта:

git remote add origin git@gitlab.com:account/project_name

Шаг 3. Самый важный шаг для существующих проектов, особенно интернет-магазинов. Нам нужно выбрать файлы и директории, которые мы будем игнорировать. Вы же не хотите следить за изменениями внутри jpg-изображений ваших товаров?

Игнорируемые файлы настраиваются в папке .git/info/exclude

Обратите внимание, что папки, которые начинаются с точки, по умолчанию скрыты. Поэтому установите флажок «Показывать скрытые и системные файлы» в вашем SFTP-клиенте (я пользуюсь Transmit). Чтобы игнорировать картинки, просто укажите в этом файле с новой строки «*.jpg». Также рекомендую игнорировать архивы, логи, pdf и все остальное, что не имеет дела к программированию.

Шаг 4. Добавляем в проект все файлы, кроме игнорируемых:

git add .

Точка здесь означает «все файлы». Если у вас большая современная CMS, это займет некоторое время. Но не очень большое, если ожидание затянулось, можно прервать операцию командой CTRL+C и еще раз проверить, все ли файлы вы игнорируете на шаге 3.

Шаг 5. Делаем первый коммит:

git commit

Нас попросят ввести комментарий к коммиту, а затем дело сделано. Теперь нужно только передать всю нашу работу в GitLab:

git push -u origin master

Собственно, на этом все. Заходим на GitLab и видим, что файлы проекта успешно загрузились:

Следующим этапом я буду это прекрасное дело клонировать у себя на локальной машине, чтобы максимально близко к реальности оттестировать Git и всю эту технологию.

Чтобы при очередной правке не поломать сайт, были придуманы специальные системы, которые следят за изменениями файлов и позволяют вернуть время вспять. Попутно также решается проблема работы двух и более разработчиков над одним проектом — они могут работать параллельно и не мешать друг другу, а когда настанет время внедрения, их работа будет автоматически (если повезет) или с помощью главного разработчика объединена.

Я всегда пользовался Mercurial (HG) для контроля версий. Она просто ставится, у нее легкие запоминающиеся команды и разобраться в ней очень просто. К ней также есть много приложений-визуализаторов, которые показывают изменения, ветки, коммиты и прочие радости не в виде командной строки, а в пользовательском графическом интерфейсе. И в целом технология меня устраивает, но ведь все почему-то вокруг меня уходят из Mercurial в его конкурента — Git. Сегодня я решил, что не должно это пройти мимо меня, и начал изучать что к чему. По факту, конечно, это такая система контроля версий, просто к ней прикручено гораздо больше интересных сервисов, а для визуализации процесса разработки уже и программа-то не нужна — все делают специализированные онлайн-сервисы, например GitLab. Схема работы строится следующим образом: на сервере инициируется репозиторий, потом он клонируется на gitlab и эта связь постоянна. Разработчики не получают доступ к серверу! Они могут скопировать сайт с gitlab к себе на сервер, провести доработку, оттестировать ее и отправить на gitlab обратно. И оттуда уже доработка пойдет в бой, на главный сервер. На мой взгляд, это очень удобно и практично с точки зрения безопасности бизнеса — сервер всегда в руках бизнеса, любую доработку можно откатить, если все пошло совсем не так. Главное не забывать делать резервные копии баз данных.

Пока я на самом начале своего образовательного процесса по GitLab, но мне уже нравится. Что особенно хорошо, на каждом этапе настройки даются необходимые для выполнения на сервере команды:

Невероятно правильный подход. Получается, что порог входа в системы контроля версий значительно снижается. Все-таки нужно признать, что Mercurial изучить чуточку сложнее, во многом из-за страшного вида документации на десятки страниц, где для старта нужно всего 2-3 команды, как на скриншоте выше.