Деплой что это такое
Docker: На старт. Внимание. Деплой
Как часто вам приходилось настраивать окружения сервера для деплоя вашего приложения (например веб-сайта)? Наверняка чаще чем хотелось бы.
В лучшем случае, у вас был скрипт, который все это делал автоматически. В худшем случае, это могло выглядеть вот так:
Выше я описал то, что называется vendor lock-in. Для разработки приложений, в частности серверного типа, это явление становится большой проблемой. В данной статье мы рассмотрим одно из возможных решений — Docker. Вы узнаете, как создать, задеплоить и запустить приложение на его основе.
/Disclaimer:/ Это не обзорный доклад о Docker. В конце этой статьи приведен список полезной литературы, которая описывает работу с Docker лучше. Это первая точка вхождения для разработчиков, которые планируют деплоить node.js приложения при помощи Docker контейнеров.
Разрабатывая один из своих проектов, я столкнулся с отсутствием подробных статей, что породило немалое количество велосипедов. Этот пост с небольшим опозданием пытается исправить недостаток информации по теме.
Что это такое и с чем его едят?
Простыми словами, Docker — это абстракция над LXC контейнерами. Это значит, что процессы, запущенные при помощи Docker, будут видеть только себя и своих потомков. Такие процессы называются Docker контейнерами.
Для того, чтобы иметь возможность создавать какие-то абстракции на базе таких контейнеров, в Docker существует образ (/docker image/). На базе Docker образа можно конфигурировать и создавать контейнеры.
Существуют тысячи готовых Docker образов с уже предустановленными базами данных, веб серверами и прочими важными элементами. Еще одно преимущество Docker состоит в том, что это очень экономичный по потреблению памяти инструмент, так как он использует только необходимые ему ресурсы.
Знакомимся ближе
На установке долго останавливаться не будем. Процесс за последние несколько релизов упростили до нескольких кликов/команд.
В этой статье мы разберем деплой Docker приложения на примере серверного Node.js приложения. Вот его примитивный, исходный код:
У нас есть как минимум два способа упаковки приложения в Docker контейнер:
Для начала скачаем официальный node.js образ:
Команда docker pull скачивает Docker образ. После этого можно выполнить команду docker run. Это создаст и запустит контейнер на базе скачанного образа.
Эта команда запустит index.js файл, произведет маппинг 3000 порта на 80 и выведет id созданного контейнера. Уже лучше! Но на одном CLI далеко не уедешь. Давайте создадим Dockerfile для нашего сервера.
Данный Dockerfile описывает образ, от какого наследуется текущий вариант, а также директорию, в которой начнут выполнятся команды контейнера и команда копирования файлов из директории, в которой запускается сборка образа. Последняя строчка указывает, какая команда запустится в созданном контейнере.
Наш контейнер готов. Мы можем запускать его при помощи команды docker run. Таким образом, мы решаем vendor lock-in проблему. Запуск приложения уже не зависит от окружения. Код доставляется вместе с Docker образом. Эти два критерия позволяют нам деплоить приложение в любое место, где мы можем запустить Docker.
Деплой
Не так страшны первые 99% как оставшиеся 99%.
После того, как мы выполнили все инструкции выше, сам процесс деплоя уже становится делом техники и вашего окружения разработки. Мы рассмотрим 2 варианта деплоя Docker:
Ручной деплой
Данный вариант хорош, если у вас нет какой-либо среды непрерывной интеграции. Сперва нужно загрузить Docker образ в место, доступное staging серверу. В нашем случае это будет DockerHub. Каждому пользователю он бесплатно предоставляет один приватный репозиторий образа и неограниченное количество публичных репозиториев.
Авторизуемся для доступа к нашему DockerHub:
Загружаем туда наш образ: docker push username/helloworld-with-docker:0.1.0.
Далее заходим на staging сервер (напоминаю, на нем уже должен быть предустановлен Docker).
Для деплоя нашего приложения на сервере нам потребуется выполнить всего одну команду:
И все! Проверьте локальный регистр образов. Если не найдете нужный результат, введите username/helloworld-with-docker для проверки DockerHub регистра. Образ с таким именем найдется в регистре, так как мы его туда уже загрузили. Docker скачает его, создаст на его основе контейнер и запустит в нем ваше приложение.
Теперь каждый раз, когда вам нужно будет обновить версию вашего приложения, вы можете делать push с новым тегом и просто перезапускать каждый раз контейнер на сервере.
P.S. Данный способ не рекомендуется, если есть возможность воспользоваться Travis-CI.
Деплой при помощи Travis-CI
Первым делом добавим в Travis-CI данные DockerHub. Они будут хранится в переменных окружения.
Далее нам нужно авторизоваться и загрузить образ:
Также доставка образа может запускаться из Travis-CI различными способами:
Беглый деплой или как развернуть front-end за 15 минут
Уже очень давно у нас стоял вопрос: как же просто и быстро деплоить front-end проекта?
Мы думали насчет такого инструмента, как Jenkins. Многие, кто настраивал его, знают: настройка занимает немало времени и, что еще важно — затрачивается много ресурсов системы. Поднять его на сервере значит выделить полтора гигабайта памяти. Такое себе удовольствие, когда у тебя 500 мегабайт на всё, например.
Альтернативный вариант — Mina. Это отличное решение, и мы используем его в Ruby проектах. Но как быть, если у тебя только front-end? Ставить Ruby и делать Bundle? Нет, это слишком сложно. Mina, конечно, имеет большой функционал, но мы хотим это делать на NodeJS без лишних телодвижений.
В итоге мы писали Bash скрипты, но это нас утомило. И нам в голову пришла идея написать свой небольшой сервис для деплоя front-end приложений, который будет:
И мы сделали Runy — удобный и практичный инструмент для деплоя front-end.
Все что нужно для его настройки и первого деплоя после установки пакета — это три команды:
init — создать конфиг и внести свои данные в него
setup — создать структуру проекта
deploy — задеплоить ваш проект
Данный модуль упростил нам жизнь! Теперь деплой проходит одной командой. Быстро и просто. Когда к нам приходят новые разработчики, можно дать им доступы к dev/stage серверу, чтобы ребята могли сами деплоить. Junior разработчикам тоже будет полезно, для использования не нужен порог вхождения, а в дальнейшем они могут разобраться в модуле и приобрести новые знания.
Немного о технической части (более подробный мануал есть на github). На данный момент, Runy имеет следующие команды: init, setup, deploy, unlock, rollback.
Создает конфиг файл в месте вызова команды. Вам следуют внести в него свои данные. Как видно, мы используем подключение по ssh-agent, так что никакие пароли в конфиге находиться не будут.
Setup
Deploy
Данная команда имеет некую защиту, в одно и тоже время только один человек может производить деплой.
Команда делает следующие действия. Создает временную папку, устанавливает проект, выполняет список ваших команд из конфиг файла (commands) для подтягивания зависимостей и сборки приложения, создает новую релиз папку, переносит туда только что собранный проект, проверяет количество релизов и удаляет старые (сейчас хранится 3 релиза), создает символическую ссылку на текущий релиз (текущий релиз всегда будет доступен по данному пути your-remote-path/current), обновляет файл с цифрой релиза, чистит папки.
Unlock
Удаляет защитный файл, который создается при исполнении команды deploy. Вообще файл удаляется автоматически и даже при обработке ошибок, но на все случае жизни существует данная команда.
Rollback
Возвращает обратно символическую ссылку на предыдущий релиз и удаляет текущий.
P.S. У нас еще есть идеи по развитию этого инструмента, вы также можете поучаствовать в развитии проекта, создавая/делая задачи здесь.
Пусть deployment каждого разработчика станет удобнее и быстрее.
Heroku и React: деплоим свое первое приложение
Всем привет. Вместе с весной в OTUS пришли новые курсы, знакомить с которыми мы начинаем прямо сегодня. Уже сейчас открыт набор на курс «React.js разработчик». Подробнее о курсе можно узнать на бесплатном вебинаре, который пройдет 11 марта. В рамках этого же вебинара будет разработано небольшое веб-приложение на ReactJS.
А сейчас предлагаем вам прочитать статью о деплое своего первого приложения, которую написал наш внештатный автор.
Стартовый шаблон Create-react-app и Heroku — это прекрасные инструменты для быстрого создания работающих в облаке приложений, однако документация React и Heroku включает в себя на удивление немного информации о том, как все-таки выкатить свое React-приложение на Heroku. Описанные в этой статье шаги сработают на любом проекте, созданном с помощью create-react-app. В нашей статье мы задеплоим на Heroku простое todo-приложение с самым минимальным бекэндом, просто чтобы посмотреть на сам процесс. Но обо всем по порядку:
Что такое вообще Heroku? Зачем он мне нужен?
Heroku — это облачная платформа как услуга (PaaS), которая поддерживает множество языков программирования (и этим она очень хвастается и выделяется). История Heroku началась в 2007, и тогда первым языком программирования был Ruby. Теперь она поддерживает Java, Node.js, Scala, Clojure, Python, PHP и Go.
А зачем мне это облако? Я вот могу хостинг недорогой купить
Да, вы можете купить себе любой хостинг и установить туда Node.js сервер, если на хостинге поддерживается эта услуга. Однако облачные платформы обладают такими качествами, как, например, эластичность и учет потребления — если на ваш сервис заходит очень много пользователей, тогда платформа скорее всего автоматически (или вы сами с помощью предоставленных платформой инструментов) отмасштабирует или сузит поток. Учет потребления означает, что вы заплатите только за те ресурсы, которые оказались востребованы. Облачные платформы имеют еще множество преимуществ, с полным списком можно ознакомиться здесь. Ну а мы перейдем непосредственно к деплою.
Создание своего React приложения
Что это вообще за шаблон create-react-app? Хоть немного заниматься разработкой React приложений и не знать про него, наверное, невозможно. Этот шаблон предоставляет React, React-dom, Webpack, ESLint «под капотом». Конечно, вы можете сами собрать свое React — приложение, но зачем плодить себе сложное приложение с кучей зависимостей, когда можно воспользоваться уже готовым велосипедом?
Для начала практических шагов убедитесь, что у вас установлена Node.js.
Что бы создать новое приложение, введите в консоль следующие команды:
Можете поставить это приложение себе и развернуть его при помощи:
Дальше у нас есть невероятная возможность поиграться и создавать свои дела. Однако все возможности, которые есть в данном приложении — это сохранять дела в state. Никакой подвязки к серверу или хотя бы к localStorage я не делал, цель этой статьи состоит не в этом. Предположим, что я очень сильно параноик и свои дела буду записывать только за одно включение вкладки браузера.
Создание своего favicon
Зачем нам вообще нужен Node.js сервер, если никакой работы с БД не проводится? С помощью сервера мы будем отдавать favicon и весь остальный код. В нашем React-приложении заходим в папку public и удаляем оттуда шаблонный favicon.ico. Я возьму иконку отсюда и перенесу ее в папку public.
Создаем свой Express-сервер
Пишем в нем следующее:
Так как мы используем пакеты express, express-favicon и path, их нужно проинсталлировать:
В package.json изменяем команду start на следующую:
Запускаем build
Дальше нам нужно забилдить приложение с помощью следующей команды:
Неплохо было бы потестировать, что наше приложение работает корректно. Для этого набираем yarn start и оцениваем, насколько корректно оно работает.
Скрываем sourcemap
Непосредственно деплой
Потом вводим имя вашего приложения. В моем случае это будет todoisakura313, потому что использовать спецсимволы и нижние подчеркивания в имени приложения нельзя:
Потом мы отправим наш билд с помощью следующих команд:
На этом все! Спасибо за внимание. С работающим приложением можно ознакомиться здесь, а с его готовым кодом — здесь.
А тех, кто дочитал до конца, мы приглашаем на еще один бесплатный вебинар, в рамках которого Вы узнаете сильные и слабые стороны самых популярных JS-фреймворков для Frontend-разработки, поймете для каких задач какой из фреймворков лучше подойдет и сможете определиться, что лучше изучать.
Как разработчику-одиночке правильно построить процесс создания и деплоя ПО — отвечают эксперты
Авторизуйтесь
Как разработчику-одиночке правильно построить процесс создания и деплоя ПО — отвечают эксперты
Часто разработчики-одиночки не пользуются привычными инструментами и практиками вроде VCS, CI/CD, которые используют в командах. Спросили у экспертов, правильно ли они делают и как можно самому построить процесс разработки, сопровождения и деплоя.
ведущий программист компании Polarr Inc.
Разработчик-одиночка в общем случае мало чем отличается от команды разработчиков с точки зрения построения собственных процессов. В случае с одним человеком, который работает над каким-то продуктом, такой разработчик одновременно берёт на себя все обязанности по работе над продуктом в виде полного цикла «заботы» о нём:
По большому счёту, разработка ПО — это цикличный процесс с определёнными фазами. Работа непосредственно над продуктом сменяется сбором фидбека. После этого происходит выпуск новой версии, снова сбор фидбека, снова работа над продуктом.
Именно с точки зрения цикличной работы над продуктом, имеет смысл использовать следующие процессы при работе над ним одному человеку:
главный специалист отдела разработки программного обеспечения, Okko
В наши дни я не могу представить себе процесс написания кода без Git. Даже если работаю один над пет-проектом.
Во-первых, я всегда знаю какие файлы я редактировал и что именно я в них менял. Это позволяет править код без страха, и гораздо легче находить причины неработоспособности кода. Любые изменения видно после долгого перерыва работы над проектом и даже после перезагрузки компьютера. Что невозможно при использовании ctrl + z.
Во-вторых, если в процессе работы весь проект оказался сломан или по каким-то причинам не получилось реализовать функционал или я понял, что это всё была плохая затея, я могу одной командой вернуть предыдущую версию проекта. Или даже проводить эксперименты на тестовой ветке, а делать фичи в стабильной ветке.
Во избежание проблем с самописными решениями, я могу посоветовать воспользоваться утилитой Ansistrano. Она делает всё, что описано выше и при этом заходить на сервер не обязательно. Можно запустить скрипт прямо со своей машине. А сценарии деплоя и отката описываются в декларативных yml-файлах. Плюс, все действия идемпотенты и есть гибкие настройки: ветка, тег, коммит с которых производить деплой, количество сохраняемы резервных копий и так далее.
Для меня это минимально комфортный уровень работы над проектами. Автоматический деплой спасает от рутинных действий и уберегает от ошибок, вызванных человеческим фактором.
Если пойти чуть дальше, то можно освоить базовые функции Bitbucket Pipelines или GitHub Actions. Скрипты у них тоже пишутся в yml-файлах, только синтаксис везде разный. Но плюсом получаешь заготовленные сценарии, которые, например умеет использовать кеши npm, что значительно ускоряют процесс, и много других фич. Так же можно организовать автоматический деплой по мерджу в master или добавлению тэга. И это уже будут настоящие CI/CD.
Самое главное, что потратив один раз небольшое количество времени и сил на освоение этих технологий, получаешь крутые и удобные инструменты, которые облегчают жизнь каждый день и экономят время.
заместитель директора по разработке «ВИСТ» (группа «Цифра»)
Каждый случай индивидуален. Все зависит от объема работ, процесса согласования результатов, сроков поддержки, модернизации и многих других факторов. Зачастую кажется, что все эти системы контроля версий только увеличивают время на разработку.
Например, когда проект небольшой и есть четкое ТЗ, подробно покрывающее потребность заказчика и выполнимое в конкретный отведенный срок без возможности дальнейшей модернизации – все эти дополнительные сложности могут быть и не нужны. Написал на локале, показал заказчику, сдал проект и доволен. Но даже в таком случае системы контроля версий не будут лишними. Они могут застраховать разработчика от нечаянного удаления проекта или возврата к коду, который ранее казался неправильным (откат к прошлой версии). Но опять же если мы пишем калькулятор, то это не нужно.
Но такие проекты существуют только в идеальном сферическом мире, в вакууме. Чаще всего заказчик сам не знает, что конкретно ему нужно. После выполнения проекта по ТЗ фантазия заказчика только начинает разыгрываться, и он просит добавить в свой продукт все больше и больше фич.
В этих ситуациях без системы контроля версий не обойтись. Она позволит сократить время на согласование, так как можно накидать прототипов разных интерфейсов в разных ветках, не внося больших правок в продакшн код. Показать их заказчику, скорректировать (повторять до полного удовлетворения заказчика) и только после этого мерджить в прод. Причем работать можно параллельно над несколькими фичами, так как устраивать демонстрацию каждой отдельной фичи очень накладно по времени, а время заказчика надо уважать.
Для более крупных проектов контроль версий просто необходим, даже если разработчик всего один. Так как заказчик, с которым программист очень приятно и продуктивно поработал год назад, может вернуться и предложить новое сотрудничество. А с тех пор ноутбук мог умереть, у заказчика мог умереть сервер и вообще «метеорит упал на Челябинск». Нынешние бесплатные системы контроля версий облачные и вероятность потерять с них данные достаточно мала – следовательно даже через год можно вернуться к внесению новых фич к старому софту.
Что касается CI\CD – его необходимость также индивидуальна для каждого проекта. Этот инструмент очень сократит время при непрерывной разработке (когда с первого прототипа и до конечного варианта софт уже используется заказчиком). Все опять же зависит от объема. Если это калькулятор и его используют 1 раз в день – можно остановить работу своего приложения и на флешке поставить новую версию. Но когда софт большой, состоит из множества модулей и нагрузка на него непрерывна, то процесс обновления может занять значительное время. В этом случае даже соло программисту стоит задуматься об автоматизации этого процесса (включая тестирование, дабы не выкатить случайно код, который все положит).
Резюмируя, хочу сказать, что эти общепринятые инструменты нужны не только для организации командной разработки, а в первую очередь для увеличения качества кода, его сохранности и ускорения развертывания его у заказчика. И целесообразность их использования зависит исключительно от самого проекта. Если проект на неделю – не стоит и заморачиваться, а в случае, если проект будет обеспечивать стабильным доходом разработчика многие годы – не поленитесь обезопасить свой доход.
эксперт направления аналитики данных Технологического центра Accenture в Ростове-на-Дону
В настоящее время доступны самые разные инструменты, как полностью автономные, так и требующие постоянного подключения к удалённым серверам, повышающие качество работы и позволяющие сократить время на её выполнение.
Использование систем контроля версий является обязательным условием для продуктивной работы по ряду причин. Самые очевидные — наглядная демонстрация истории развития проекта, выявление, какие из его участков потребовали больше внимания, а также защита от случайных ошибок, опечаток или ненамеренных правок.
Системы CI\CD также обязательны к применению, важно лишь правильно автоматизировать выполнение наиболее частых и повторяющихся действий и в целом изначально закладывать возможности для полной автоматизации сборки и публикации артефактов проекта.
К сожалению, без должной самодисциплины формируются неподдерживаемые скрипты автоматизации, привязанные к рабочей станции разработчика, поэтому крайне желательно периодически выполнять повторную инициализацию проекта и его окружения с нуля, пустой директории. Все шаги должны быть самоочевидны и необходимы, без лишних сторонних условий и зависимостей.
Исключительно полезно настраивать развёртывание проектов через такие платформы как GitLab и TeamCity. Их использование бесплатно для небольших команд, а доступного функционала более чем достаточно для малых и средних проектов. Это позволит соблюдать верный баланс между поиском решений для частных проблем автоматизации, которые присутствуют в каждом проекте и оптимальным использованием ресурсов современных платформ.
Полученный опыт позволит в дальнейшем в кратчайшие сроки включиться в работу любых команд в качестве эффективного и востребованного специалиста.
Как правильно организовать деплой приложения?
Вчера я понял, что веду свои _дела_ каким-то абсолютно варварским способом. Использование git и bitbucket уже никого не удивляет.
Из-за продолжительной работы конвейера, который выпускает велосипеды по моей разметке появилась необходимость облегчить некоторые этапы работы.
Прямо сейчас имеется мой пк на котором разрабатывается _очередной_ сайт и два компьютера, которые можно назвать серверами. Да черт с ним, два невероятно полноценных сервера — development и production сервера. ( а какой размах? )
Я честно воспользовался гуглом, в стране в которой отсутствует реестр незаконных сайтов, и понял, что мою маленькую проблему решает:
Но вот моя компетентность оставляет желать лучшего — я решил освоить тестирование. Каюсь, до селе пусть и знал, но не воспринимал тестирование любого вида, как должное. Пора становиться намного лучше!
С самими тестами я как-то разберусь, но где их _правильно_ было бы запускать? У меня? Уже на стороне девелопмент сервера?
И предположим, что велосипед моего производства вышел на свет в виде готового сайта на дев-сервере. По-старинке, по фтп на продакшн?
Есть ли возможность у гита вытягивать с удаленного репозитория только обновления файлов, которые сейчас существуют?
Т.е. есть желание сделать такие операции в результате которых с дев-сервера можно сливать на все файлики сайта, а только их часть.
Прошу обратить внимание, что мои вопросы могут быть заданы совсем неверно или не очень верно. Не сердитесь. 🙁
Я увидел в Вашем вопросе две части.
Как правильно организовать деплой (выкладку работоспособного кода на сервер)?
В самом простом случае Вам подойдет связка ssh + git pull на сервере. В этом случае на сервер будут доставлены патчи коммитов, которые есть в репозитории, но еще не появились на сервере, т.е. «только обновления файлов, которые сейчас существуют». Этот метод довольно подробно обсудили в ответах на другой вопрос.
Инструменты просты, переход на них — дело одного выходного дня, и может быть сопряжен со сложностями только в связи с новизной.
Как организовать процесс тестирования?
Если Вы еще не определились с методикой тестирования (Test Driven Development, Behavior Driven Development, Лень-Driven Development), то Вам следует для начала заняться именно этим.
Скорее всего, тесты будут выполняться на Вашей локальной машине, пока Вы пишете код. Используя RSpec, я держу открытым Guard. Guard отслеживает изменения в коде и запускает набор юнит-тестов, которые покрывают измененный код. Весь процесс занимает не больше минуты-двух, и особо не напрягает. Как только я вижу провалившийся тест, я меняю код до тех пор, пока он не станет зеленым. Пока тестов мало (это не самый лучший знак, к слову), Вы работаете один, локального запуска перед деплоем может оказаться достаточно — например, чтобы проверить релиз на доступность критического функционала: регистрации, покупки, создание постов и т.п.
В какой-то момент речь может зайти о Continious Integration. Это возможность иметь стабильный билд в любой отрезок времени, а так же принимать решение о годности каждого отдельного коммита. Сопряжено с деплоем кода на integration-сервер и запуском на нем тестов. Скорее всего, это Вас не интересует, если Вы не работаете в команде. Но, для полноты картины, Вы можете понаблюдать за билдами на Travis CI известных Open Source проектов: Symfony 2 и Ruby on Rails.
Таким образом
Вы не указали, какие конкретно инструменты для разработки Вы используете. Если же с деплоем все гораздо проще, то при выборе инструментов для тестирования я рекомендую Вам ориентироваться на те, которые нативны для Вашего основного фреймворка и языка (PHP, если правильно понимаю) и привычны их пользователям. Это позволит быстро применить устоявшиеся практики к Вашему проекту и понять всё на деле.
Приведите в порядок Ваш репозиторий с кодом, используйте mina для деплоя и запускайте тесты на Вашей локальной рабочей машине. Как только Вы почувствуете, что этого не достаточно — Вы наверняка уже будете знать, куда шагать дальше.
Не лучше ли использовать технологии вроде bash scripting для деплоя вместо всех этих капистранов? Преимущества:
1) bash-скрипт простой и короткий. Его легко и быстро написать. Во всяких капистранах надо сначала полдня изучать инструмент, потом думать, каким костылем можно заставить его делать то, что нужно.
2) bash-скрипт легко проверить на отсутсвие ошибок и не надо полдня отлаживать
3) bash-скрипт делает ровно то, что в нем написано. Что сделает сложная система, написанная другим человеком неизвестной квалификации — никому неизвестно
4) Простое решение лучше сложного
У автора вопроса, как я понимаю, речь идет о несложном приложении, а не мегасистеме с десятками серверов и сервисов и использовать сложные системы вроде CI, юниттестов это излишнее усложнение жизни.
Плюс, как видно из описания Mina, это чрезвычайно тяжелый и сложный инструмент: вы добавили пару строчек в файл, логично закачать измененный сервер на файл за полсекунды и успокоиться, но она будет делать репозитории, выкачивать что-то, собирать, загружать… боюсь, это не способствует быстрой разработке.
Опять же, вы советуете использовать юнит-тесты. А я советую использовать функицональные тесты. Почему? потому, что функциональные тесты проверяют, правильно ли работает приложение. Если все правильно — его можно выливать на продакшен. А прохождение юнит тестов не гарантирует правильной работы приложения. А время на них расходуется. Вопрос, зачем они тогда нужны.
В общем, советую автору вопроса сделать самую-самую простую систему деплоя на основе bash скрипта/нескольких скриптов и FTP/SFTP и не мучаться.
Инструменты для разработки? PHP, MySQL, свои велосипеды (никакого yii).
Методика тестирование? TDD. 🙂
Очень здорово! С этими вопросами покончено! Спасибо.
Значит на продакшн проще по-старинке, да?
И всё-таки может ли гит выкачать определенные папки из конкретной ветки с указанного удаленного репозитория?
Egorinsk — Mina, если Вы этого не заметили, сама по себе генерирует баш скрипт и транслируется из Ruby напрямую в bash. Это очень легкий инструмент и отдельного внимания заслуживает DSL с помощью которого и генерируется конечный баш-скрипт. По поводу «сложной системы», «другого человека» и «неизвестной квалификации» — предлагаю периодически думать.
По поводу тестов — я привел пример того, как запускать тесты. Автор просил именно этого совета. И конечно юнит-тесты не панацея.
Автор, уточните пожалуйста, с какой целью Вы хотите выдергивать отдельные папки из гита? Сразу скажу, что это невозможно 🙂
shebanoff, на самом деле мои велосипеды разных моделей выходят с достаточно постоянной частотой.
Иногда в эти разработки прокрадываются баги и нужно на разных сайтах вносить одни и те же изменения в файлы _ядра_ велосипеда.
К сожалению, чтобы исправлять один продукт конвейера я придумал другой — параллельная линия выпуска. Сделать так, чтобы при коммите в ветку мастер изменения файлов ядра вносились на разных сайтах-донорах-клиентах.
Без абстракции всё выглядит примерно так: есть мой микро-фреймворк который реализует базовый функционал простого сайта — я его назвал ядром. И всякие модули к нему, например галерея с множественной загрузкой картинок. На одном сайте такой модуль нужен — на другом нет. Но ядро везде одно и тоже.
Вопрос стоит таким образом: как производить обновления основных компонентов сайта (ядра) и при этом не лазить на каждый сайт по фтп?
Разрабатываю один, но поддерживать приходится несколько сайтов моего производства. Критические вещи нужно фиксить. Подумал, что такое ухищрение с гитом решит мою проблему.
Есть решение? Можно вызвать более опытных товарищей на скайпообщение?