Archive for the ‘svn’ Category

ПКМГ. rsync по ssh для обновления сайта.

Сентябрь 14, 2008

В ноябре 2007 года я публиковал roadmap проекта-мечты. Прошел год, жизнь внесла свои коррективы, я узнал немного нового. Поэтому видиние того, как хотелось бы разрабатывать сайты чуть-чуть изменилось. Попробую его структурировать, чтобы и самому было понятнее =)

CIS — continuous integration server

Начинать придется с этой малопонятной штуки. Насколько я понял из русской и английской (лучше) Wiki эту штуку придумали незабвенные Фаулер с Беком. Где-то на рубеже веков. Придумали для всеяЫнтерпрайзЖавы, но идея ожила и распространилась дальше. Даже книга на русском есть.

Честно скажу, этой штукой я займусь не скоро, но уж больно интересна идея. Хорошие обсуждения можно найти на форуме по гибким методологиям, где идут очень интересные обсуждения, заставившие меня почувтсовать, что я работаю в детском саду, а не в девелоперской конторе 😉

Но для начала я вытащил из всей этой идеи Phing. Те, кто работал с всеяЫнтерпрайзЖабой, знают, что есть такая штука, как Ant. Это такой трудолюбивый муравей, которого создали люди, считающие, что xml намного понятнее, чем файлы make. В двух словах, он нужен для того, чтобы билдить из исходного кода то, что можно потом задеплоить. Вы ещё здесь? =)

Так вот меня этот Phing здорово зацепил, ибо я всегда любил всё автоматизировать. Ведь однажды обученный компьютер ошибается гораздо реже, чем человек. Надо просто объяснить ему что делать =) В принципе, у нас в пыхоРазработке не сильно много проблем, не то что в ынтырпрайзЖабе. Но тоже хватает. И среды dev/prd отличаются, и изменения в DB надо учитывать, короче, есть где развернуться автоматизатору. Можно держать все изменения в голове и обновлять только нужные файлики, а базы обновлять одновременно. Можно вообще на prd разрабатывать =) Но не зря же мы svn используем и вообще пытаемся отмыться от приставки «быдло» в слове кодинг =)

Временным решением пробдем с конфигами и прочими паролями к БД может быть привязка к рабочей директории. Об этом хорошо писал Кузьма Феськов в последнем PHPInside. Где-то год назад. Костыль, но всё ж лучше, чем каждый раз вспоминать, что не надо заливать разработческий конфиг на продуктивный сервер =)

Далеко меня уже занесло, постараемся вернуться назад. Итак. План теперь таков:

  1. Пишем код, тестируем, отлаживаем. Добиваемся работоспособности.
  2. Коммитим в svn
  3. В post-commit hook вызываем phing
  4. Phing пакует наш проект в продуктивный вид, заменяя файлики конфигов, убирая ненужные всякие фишки svn и Eclipse.
  5. Лезем (не сами, скриптом) на продуктив. Пакуем текущую версию сайта в архив. Сливаем себе.
  6. Заливаем изменения с помощью rsync over ssh.

По-моему неплохой план =) первые 2 пункта уже вроде как отлажены. Осталось разрбраться с остальными. Так как сегодня вечер воскресенья, пришлось взять самый маленький и скучный шестой пункт =)

Rsync over ssh

Ну наконец-то. Процедура беспарольного соединения с удаленным сервером обсосана уже вдоль и поперек (да, именно так =) на просторах инета и рунета. Например, здесь.

А дальше чистая bash-магия, которая выглядит вот так (подсмотрено здесь, одна строка!):
rsync -zrptL --delete-after -e "ssh" /local/folder/ remote-server.ru:/remote/folder

За разъяснениями — в man или источник. Только будте аккуратны. Оно удаляет без права переписки. Именно поэтому я хочу для начала бэкап наладить, а потом уже это использовать это заклинание =) Кстати, обращайте внимание на слэшики в конце путей. Они важнее, чем вы думаете.

Именно за это я люблю *nix. Весь вечер ты читаешь маны, бродишь по сайтам, читаешь чуть ли не китайские форумы. Зато потом одной строкой ты захватываешь мир. Продложение следует.

Реклама

Управление сторонними библиотеками в Subversion.

Январь 28, 2008

В этом блоге я ни разу не постил переводы. Повода не было. Но вот в RSS пробежала статья, описывающая правильное управление внешними библиотеками в Subversion. Она мне настолько понравилась, что я решил опубликовать её вольный перевод. К сожалению, времени потестировать рецепт у меня не было, поэтому буду переводить «as is». Если заметите какие-нибудь неточности, отпишите в комментах, исправлю.

Subversion Externals

В Subversion существует удобный механизм управления внешними библиотеками, который позволяет автоматически экспортировать код из других репозиториев в рабочий проект. Это svn:externals. Этот пост создан в качестве напоминания самому себе, о том, как это реализовать. Потому что каждый раз забывая, я вынужден гуглить. А решение, к которому я прихожу каждый раз одно и то же.

Для начала, предположим, что у нас в репозитории есть папка lib/, и мы хотим положить в неё код из папок library/ и incubator/library/ проекта Zend Framework. Конечная структура папок выглядит следующим образом:


myApplication/
    lib/
        incubator/Zend/
        Zend/

Для этого необходимы следующие заклинания:


$ cd lib/
$ export SVN_EDITOR=vim
$ svn propedit svn:externals .

(Разумеется, стоит заменить vim на редактор, привычный Вам)

В запустившемся Vim’е (emacs’е, nano) необходимы следующие строки:


incubator http://framework.zend.com/svn/framework/branch/release-1.0/incubator/library
Zend http://framework.zend.com/svn/framework/branch/release-1.0/library/Zend

Стоит отметить, отметить, что release-1.0 это текущий релиз ZF, а следующий будет release-1.5. Если вам необходима текущая версия ZF 1.5, то это будет release-1.5PR

Сохраняемся, выходим из редактора и видим следующее сообщение:

Set new value for property 'svn:externals' on '.'

Вот и всё! Не забываем закоммититься и теперь для поддержания ZF в состоянии актуальности не забываем запускать svn up.

Subversion. Установка и настройка. День второй.

Ноябрь 15, 2007

Вводная

Сегодня будем заниматься кристаллизацией workflow. Т.е. пытаться понять, как именно врезать svn в процесс разработки. Я уже приводил свои мысли на этот счет. Мои идеи были сформированы под воздействием пары веток форума и нескольких невнятных статей ;). Правда совершенно недавно я наткнулся на статью. в которой есть даже картинка 😉 Но в этой статье описана теория (зато есть картинка, очень наглядная). Меня же в силу неМифических сроков сдачи интересует практика. К ней и приступим.

Настраиваем Eclipse 3.3

Первое, что пришлось сделать — установить права на папку /var/www и все её подпапки. На запись права были только у рута, это мы изменили, набрав в терминале chmod -R 777 /var/www. Теперь право на запись есть у всех, и мы можем спокойно с ней работать из Eclipse. Второе, что пришлось сделать, это установить права и на папку /vwr/svn/, набрав ту же команду. На будущее стоит запомнить, что репозитории и папки с проектом лучше держать у себя в домашней папке. Или в той, от имени кого запускается Eclipse. В принципе, можно было сделать и gksudo eclipse, но это как-то совсем против правил =)

Далее — маленький фокус. Нужно настроить папку с workspace Eclipse таким образом, чтобы разработка шла по созданным выше адресам. Т.е. текущий проект Eclipse (в моем случае) должен разрабатываться в папке /var/www/dev/. Для этого меняем workspace: «File->Switch Workspace->Other». А в окошке пишем /var/www.

Теперь надо настроить репозиторий. Переключившись на perspective SVN Repository (доступную после установки subClipse), тыкаем правой кнопкой на левой части окна и выбираем «New->Repository Location». В появившемся окне пишем file:///var/svn/, или где там у вас хранилище. Должно случиться чудо, и отобразиться структура хранилища. У меня, в силу вчерашнего дня отобразилось следующее:

  • file:///var/svn/
    • project_name
      • trunk
        • index.php 1

Checkout

Связь есть, надо делать checkout. Т.е. забирать текущую версию из репозитария себе. На доработку. Правой кнопкой на «папке» trunk и в меню выбираем «Checkout…» В открывшемся окне стоит установить верхний радиоБатон в положение «Checkout as a project in the workspace» и вписать имя проекта «dev». Таким образом, мы получим настроенный ранее в Apache структуру /var/www/dev/, которая будет доступна из браузера по http://localhost/. Отлично.

Commit

После того, как файл появился у нас в workspace, можно его отредактировать. Перейдем на perspective PHP (она пришла вместе с PDT) и отредактируем файл. Напишем что-нибудь веское, чтобы доказать себе, что оно работает 😉 Теперь в левой части окна, в PHP Explorer, который отображает нам workspace, кликнем правой кнопкой на этом файле и выберем «Team->Commit…» На что получим предложение написать что-нибудь для истории, выбрать файлы, которые необходимо закоммитить и нажать «OK».

Можно приступать…

Вот, в принципе, и всё, что я хотел узнать за сегодня. Если дойдут руки, надо будет написать внятную и подробную статью где-нибудь на Хабре (и прославиться ;), с картинками красивыми и прочим. Но это будет не раньше, чем я отшлифую навыки пользования этой связкой. Ну и на проектах не будет посвободнее в плане времени. Т.е…видимо не скоро =)

Subversion. Установка и настройка. День первый.

Ноябрь 14, 2007

Допивая крепкий чай, глядя на снег за окном, я занимаюсь тем, до чего руки не доходили уже…наверное год. Разворачиваю репозиторий и учусь с ним обращаться. Откопав где-то в закромах «Pragmatic Version Control using Subversion«, понимаю, что без этой книги было бы намного сложнее 😉

Install

До того, как установить svn, я установил Apache2.2, PHP5 и MySQL5. Вопреки всем своим привычкам, просто не захотев долго возиться, я устанавливал их через apt-get install и понял, что больше этого делать не буду. Очень уж сложно искать по системе где спрятались конфигурационные файлы, как они разбиты и что вообще происходит.

После этого, через тот же apt-get install subversion, установил svn. С ним проще, svn из исходников я не собирал и мне под него подстраиваться не надо =). Ну а чтобы subverion’у не было скучно и, просто из любопытства, я установил следующие пакеты:

  • nautilus-script-collection-svn — скрипты для правой кнопки мыши в Nautilus, что-то вроде TortoiseSVN для *nix
  • python-svn — просто ещё один визуальный клиент для svn написанный на Python
  • rapidsvn — очередной визульный клиент
  • subversion-helper-scripts — набор shell-скриптов, упрощающий жизнь хранителя хранилища =)
  • subversion-tools — ещё один набор вспомогательных скриптов
  • svn-workbench — ещё один визуальный клиент
  • websvn — модуль для web-представления репозитария, написанный на PHP, быстро заработавший после короткой настройки. Показал мне пустое хранилище 😉

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

Setup

Я не буду описывать процедуру создания двух папок для Production и Development версий проекта, настройки виртуальных хостов на разных портах. Скажу только, что у меня есть две папки /var/www/dev/ и /var/www/prod/ с вполне говорящими названиями. А доступ к ним идет через http://localhost/ и http://localhost:8080/ соответственно.

Запасшись софтом с избытком, я приступил к настроке хранилища и начал пытаться представлять как я буду с ним работать.

Для начала хранилище надо создать. Где угодно. Я предпочёл /var/svn/, чтобы поближе к ServerRoot Apache2, чтобы, в свою очередь, не запоминать слишком много ;). Смело пишем в терминале от рута:

cd /var
mkdir svn
svnadmin create /var/svn

Заодно запоминаем, что хранилищем руководит команда svnadmin.

Репозиторий есть. Теперь надо туда положить что-нибудь временное, чтобы потом оттуда это забрать и сделать рабочей копией ;). Сейчас стане понятней.

Создаем временную папку. Где угодно. Допустим, mkdir /home/svn_tmp. Кладем в неё файлик, допустим, index.php, в котором пишем:

<?php
echo "dev workin'";
?>

Теперь, находясь в этой папке импортим файлик в хранилище, создавая проект:

svn import -m "Creation" . file:///var/svn/project_name/trunk

Здесь «-m» — это добавление комментария, «.» — это все файлы текущей директории, ну а далее идет путь к хранилищу и проект, куда надо импортировать файл.

По рекомендации умной книги (и пока еще не осознав, зачем), в папке с проектом (которая project_name) существуют три поддиректории: trunk, branches, tags. О назначении каждой из них я ещё расскажу. Кстати, неверно думать, что пойдя в /var/svn/, вы увидите там поддиректорию с проектом 😉 всё хранится в псевдоБазе данных. Поэтому искать там не стоит.

Хранилище у нас есть. Проект тоже. Теперь надо сделать рабочую копию, с которой и будем работать впредь, периодически коммитя результаты в хранилище и синхронизируя с продуктивной версией. Рабочую копию я буду держать в /var/www/dev/, чтобы отлаживать было просто. И чтобы коммитить пакетами, а не после каждого сохранения. «Стоя» в папке /var/www, пишем:

svn co file:///var/svn/project_name/trunk dev

Сдесь у нас «co» — это checkout (синхронизировать с хранилищем), дальше путь и в конце название папки, где будет храниться рабочая копия. Если все прошло хорошо, то теперь у нас в папке /var/www/dev/ живет файлик index.php и скрытая папка .svn, в которой лежит мета-информация Subverion.

Это было начало пути. И, в принципе, насколько я понимаю, checkout можно было не делать. Можно было его сделать в subClipse, указав ему на репозиторий. Но это я буду проверять завтра

Проект-мечта. Осуществляем.

Ноябрь 5, 2007

Итак. Пути обратно нет. Полечимся от латентной виндузятности и забудем на пару секунд про ZS. У нас есть Eclipse! (афигеть…) Будем работать с ним. Как всегда, при работе с Eclipse, сначала нужно подобрать плагины. Установить. Попытаться поработать. … Надеюсь, получится.

Проект будет обычно-учебный, php+html+css+js+framework(codeIgniter, для разнообразия)+svn(для освоения). При таком раскладе, всё, что мне может потребоваться это:

  1. Eclipse 3.3 aka Europe с плагинами:
  2. SVN (и какая-нибудь gui-тулза, чтобы в консоли не пропасть 😉
  3. ER-Modelling Tool
  4. Syncrhonizer с удаленным ftp

Как видно, почти со всем я определился. Есть проблема с ER-диаграммами. Пока, единственное решение я нашёл в виде запуска под wine DBDesinger, почему-то их *nix-версия у меня работать не захотела. Видимо, она старовата. А коварный MySQL AB, который на основе неё собирался сделать свою тулзу MySQL WorkBench всё никак не соберется. Во-первых она «вечная альфа», а во-второых нет порта пол *nix.

Касательно синхронизации, я думаю проблем не будет, *nix. всё ж таки…

Рабочий процесс у меня в голове уже, вроде, сформировался. Действовать будем примерно, как я описывал давно-давно, придумал только пару уточнений к тому, что там было написано:

  1. На нашем девелоперском веб-сервере (локальном) делаем две папки. Production и Development.
  2. Обе делаем доступными в качестве VirtualHost. Например http://localhost/prod и http://localhost/dev
  3. Папка Production будет являться у нас по совместительству svn-хранилищем. А заодно точной копией internet-сервера.
  4. Все правки тестируются в папке Development, обкатываются и коммитятся.
  5. После чего, синхронизируем папку Production с удаленным сервером.

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

Разработка сайта с использованием Subversion

Июнь 21, 2007

Давно уже я хотел освоить svn и применить его в своих проектах. Да все не было идеи как же это сделать. Цикл разработки софта с использованием subversion был мне понятен. Однако четкого осознания как применять его в вебе не было. Однако, всё постижимо, и теперь я имею представление о цикле разработки.

Вот что получилось:

  1. Предположим, что хостинг у нас есть. И доступ к нему тоже есть, хотя бы и по FTP.
  2. Создаем репозиторий на любом компе. Если веб-сервера свои, то можно рядышком поставить ещё svn-сервер, а можно и на веб-сервере его развернуть. Но это будет ещё не скоро, поэтому сгодится любой комп, хоть даже и тот, на котором кодим. Не суть важно.
  3. Импортируем репозиторий на разработческую машину. Причем на этом же компе стоит весь необходимый софт, типа Apache, MySQL, PHP. Желательно версиями совпадающий с теми, что на хостинге.
  4. Вносим правки, тестируем. Тестировать надо не копию в репозитории, а локальную, чтобы правки вносить пачками, а не по одной строчке.
  5. Импортируем нашу протестированную и отлаженную копию в репозиторий, сопроводив её комментариями.
  6. Заливаем на веб-сервер.

Есть в этом сценарии ряд нюансов. С которыми я ещё до конца не определился.

  1. В какой среде будем разрабатывать. Есть Eclipse. В нём реализована поддержка svn. Если привыкну к нему, он и будет. Если не привыкну, тогда придётся подыскивать какое-нибудь средство для общения с репозиторием. Можно и из bash.
  2. Как заливать на веб-сервер. В идеале, должно быть инкрементальное копирование файлов. Но для этого, заливку надо запускать на веб-сервере. Т.е. на нем давать команду svn update. А для этого, нужен внешний IP для svn-сервера. А это расходы, которые пока хочется нивелировать. Следовательно, придется делать полное копирование. Для эти целей надо будет написать скрипт, который будет:
    • заходить на хостинг
    • скачивать все файлы
    • складывать их в архив на локальной машине
    • удалять их с хостинга
    • заливать на него копию из репозитория посредством svn export.

Вот такие пироги. Буду держать этот пост в тонусе при осуществлении изложенных здесь замыслов. Возможно, всё изменится 😉