С FTP на Git: история развертывания

Когда-то был файл. Это было на вашем компьютере, и вы хотели получить его на сервере.

Когда-нибудь задумывались, почему существует так много способов сделать это? В этой статье мы расскажем о некоторых основах развертывания, чтобы вы понимали, когда и что использовать. Давайте начнем!

FTP

FTP, или протокол передачи файлов , по мнению многих, является старомодным способом «создать сайт». Это протокол, который в основном означает, что существует набор правил, по которым и локальный компьютер, и хост-компьютер согласовывают и могут отправлять сообщения. FTP сам по себе не «программа», а скорее телефонная линия.

SFTP / SSH

Таким образом, если FTP является телефонной линией старой школы (которая все еще работает просто отлично), SFTP походит на сеть 4G

Он предлагает новый протокол для двух машин (но не обязательно, что он быстрее). SFTP работает от SSH, который по существу шифрует сообщения, которые передаются между двумя компьютерами; поэтому любая вредоносная сторонняя или ненадежная сеть не может получить ваши необработанные данные во время передачи.

SFTP против FTP

Если вы не совсем поняли, FTP и SFTP оба являются протоколами передачи файлов. Однако SFTP (и другие протоколы передачи на основе SSH) передает файлы и шифрует передачу. «Мне не нужно шифрование», — скажете вы. Многие люди думают так же; однако, дальновидные разработчики и современные инструменты будут склоняться к более безопасным методам. Вы слышали это раньше — лучше, чем потом сожалеть .

Но я не чувствую, что переживаю неприятности.

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

Теперь, если вы все еще немного ленивы, но вам нравится идея простого принятия, вы можете использовать SFTP практически с любым FTP-клиентом. Это более безопасно. Убедитесь, что ваш сервер поддерживает SSH (порт 22, как правило, должен быть открыт), и у вас все получится. Но смысл этой статьи не в том, чтобы заставить вас задуматься о шифровании и безопасности передачи; это заставит вас задуматься о более надежной стратегии развертывания.

Развертывание и передача файлов

«Но я не хочу проходить через неприятности». … если это твоя работа, смирись

Если вы разрабатывали какое-то время, вы, вероятно, прошли через процесс создания сайта и постоянно перетаскивали свои файлы на свой FTP-клиент (или дважды щелкали, или нажимали «синхронизировать», или …) , Технически это стратегия развертывания, хотя и не очень надежная. Конечно, во многих случаях такая стратегия будет работать нормально, особенно если вы единственный человек, который когда-либо будет касаться файлов, и вы волшебным образом никогда не перезаписываете и не удаляете важный файл. Но, опять же, вы здесь, чтобы поправиться, верно? И ты волшебник .

Развертывание , в его самой простой форме, берет некоторый код и делает его «живым» кодом. index.html файл index.html в ваш обслуживающий каталог, вы развертываете. Фактически, в конце концов, все стратегии развертывания (если вы не используете скомпилированную систему приложений) по существу перемещают файлы или версии файлов в «текущий рабочий каталог» или изменяют уже существующие. Например, вы можете внести изменения в этот же файл index.html непосредственно на сервере, и это эффективно «развернет» эти изменения в общедоступных. Но развертывание может быть намного больше.

Ваша команда когда-либо настраивала систему, которая требует, чтобы вы уведомляли всех, когда вы помещаете файл на сервер через FTP? Или, может быть, вам придется перезапустить сервер Django или Rails после изменения кода. Если вы делаете это как часть процедуры, которая заставляет ваш сайт отражать сделанные вами изменения, это является частью процесса развертывания.

Концепции контроля версий

Итак, если развертывание означает создание некоторого набора кода и файлов, как может быть намного больше, чем SFTP? «Что такое Git, и почему это должно вас волновать?» ты спрашиваешь. Git — это система контроля версий или VCS. Это одна из многих VCS, которые мы беззастенчиво выбрали в качестве наших любимых. Мы объясним почему позже, но сначала давайте поговорим о том, что это такое.

Системы контроля версий выполняют множество задач, но наиболее важным является обеспечение безопасности для разработчиков — особенно для групп разработчиков. Ранее мы упоминали, что FTP и SFTP могут быть в порядке, если вы идеальны, и вы никогда не перезапишите файл или не удалите важную папку непреднамеренно. Но если вы еще этого не сделали, не волнуйтесь — это произойдет рано или поздно. Почти наверняка это случилось с вашей командой, если вы не нашли обходной системы. Но даже эти обходные системы — боль. Например, ваш каталог CSS когда-либо выглядел так?

Если это так, вы сохраняете версии таблиц стилей, которые в конечном итоге вы объедините вместе. Кстати, Git делает это, но делает это намного лучше, быстрее и надежнее, чем вы сами. Сохраняете ли вы другой файл CSS каждый раз, когда вносите несколько изменений? На тот случай, если вы хотите вернуться к тому, каким именно был этот файл в определенный момент времени? Конечно, нет. Но Git сделает именно это для вас, и у вас нет беспорядочных разбросанных файлов и непонятных систем имен. Помимо этого, Git достаточно умен, чтобы знать, как взять ваш файл styles.css и объединить его с файлом Mary или John styles.css . Кроме того, версии Git не являются целыми файлами; вместо этого они хранятся в дельтах , что по сути представляет собой низкоуровневое представление кода различий между одним файлом и другим файлом. Это означает, что разные версии намного меньше и гораздо быстрее переносятся, когда наступает время их развертывания.

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

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

Разные версии намного меньше и гораздо быстрее переносятся, когда приходит время их развертывать.

Помимо организации, ветвления, нескольких мест назначения и надежного контроля версий, Git предлагает хуки, такие как «post-receive», которые могут выполнять любые действия, которые вы можете создать вместе. Возможно, вам нужна ветка «паук», где, когда код поступает в одну точку на вашем сервере, почтовая рассылка отправляет этот код в несколько мест (удаленных или других). Более того, использование такой платформы, как GitHub, предлагает отличный графический интерфейс для настройки хуков. Легко скажите GitHub отправлять вам электронные письма (или, если вы креативны, подключите уведомление Growl) каждый раз, когда вы получаете толчок от члена команды, например.

Существует буквально тысячи способов разработать стратегию развертывания с помощью Git. Вы можете быстро увидеть, что использование VCS для развертывания предлагает некоторые очень широкие преимущества, защиту и мощность для вашего развертывания. Как только вы потратите время, чтобы узнать достаточно о Git, чтобы создать рабочий процесс (и сделать с ним несколько ошибок), ваш процесс разработки получит огромную выгоду.

Развертывание с помощью Git: пример Barebones

Следующие команды создадут хранилище на удаленном компьютере, настроят хранилище на вашем локальном компьютере, добавят удаленное хранилище как «origin», извлекут ветку с именем «mybranch», которая будет объединена на сервере, вытолкнут «mybranch» на удаленный сервер «origin» и, наконец, снова входит в систему на сервере, чтобы объединить «mybranch» со стандартной веткой «master».

Git + Heroku: спичка в облаках

Помимо создания собственного рабочего процесса на основе Git и его интеграции с собственным сервером, вы можете использовать другие бесплатные сервисы, такие как Heroku ; Heroku — это решение для хостинга, которое позволяет вам запускать несколько строк из приложения, управляемого Git, и развертывать его в «облаке» (в данном случае на удаленном кластере серверов Linux) поверх Git практически без усилий. Потратьте несколько минут, чтобы настроить несколько вещей, и вы приступите к гонкам с несколькими строками кода для простого развертывания. Серьезно, это выглядит примерно так.

Другие подобные инструменты включают Pagoda Box , который ориентирован на архитектуру на основе LAMP, а также AppFog и PHPFog , которые очень похожи на Heroku.

Если в вашей конфигурации нет ошибок и вы следовали рекомендациям Heroku по настройке приложений, вы можете через несколько минут запустить и запустить приложения Rails, PHP или Node. О, и мы упомянули, что вы можете создавать простые приложения на Heroku бесплатно? Только после того, как вы обновитесь до большего количества экземпляров или памяти, или вам не понадобится добавить базу данных, вы начнете платить за Heroku. Другие подобные инструменты включают Pagoda Box , который ориентирован на архитектуру на основе LAMP, а также AppFog и PHPFog , которые очень похожи на Heroku. Эти опции предлагают аналогичные сервисы и интеграцию Git с разными структурами цен. Все три предлагают бесплатный вариант для ограниченной мощности сервера. Это, безусловно, большие преимущества, поскольку для настройки собственного сервера с более сложными архитектурами приложений, такими как Rails или Node, требуется много времени. Кроме того, масштабирование становится очень простым, поскольку все три из этих служб предлагают балансировку нагрузки и масштабирование до нескольких экземпляров одним нажатием кнопки. Эти службы заботятся о здоровенном администрировании сервера, поэтому вы можете сосредоточиться на создании приложений, зная, что существует хорошо документированная, безопасная и быстрая стратегия развертывания, которую вы можете использовать, когда будете готовы к публикации.

Вывод

Надеемся, что эта статья устранила некоторую путаницу относительно различий между Git (и другими VCS) и FTP / SFTP, а также того, что означает концепция развертывания. Кроме того, я надеюсь, что это побудило вас разработать собственную стратегию развертывания с помощью таких инструментов, как Git и Heroku. Если у вас уже есть стратегия, что вы делаете во время развертывания?