Выкатываем в бой

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

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

    План генштаба

    техпроцесс разработки

    Получив требования, спецификации, всевозможные рекомендации и указания, разработчик выделяет в репозитории исходного кода пространство для своих маневров. Такой областью может быть персональная ветка SVN, новый модуль в CVS или папка на файловой системе.

    Нет смысла подробно рассказывать о последующих циклах «Develop – Test – Deploy»: про них и так много чего полезного написано. Отмечу лишь важные наблюдения:
    • Приложение каждого разработчика должно использовать персональные БД и файловые хранилища. Использовать общую «помойку» — зло, порождающее серьезные ошибки.
    • Разработка автотестов не всегда оправдана: их реализация не должна отнимать больше 20% рабочего времени. Разрабатывать через тестирование – крайняя степень расточительства.
    • Чем больше участников в техпроцессе, тем чаще необходимо сливаться и проверять коллективный результат. Непрерывная интеграция сможет помочь, но ее сопровождение может оказаться накладным – нужно балансировать между автоматизацией и затратами.
    Итоговые результаты разработки фиксируются в релиз-кандидате (сливаются ветки, создается тег и пр.) и передаются в приемочное тестирование. Релиз-кандидат – это конечный монолитный продукт, в который нельзя вносить изменения. Если необходимо исправить ошибки, доработать функционал – необходимо начинать с начала и делать нового кандидата.

    Тяжело в учении

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

    Основные хинты приемочного тестирования:
    • Сценарий внедрения кандидата должен быть максимально приближен к сценарию внедрения релиза. Если в конечном релизе планируется обновить структуру БД, мигрировать данные, добавить сторонние библиотеки – сделать все это необходимо именно в той последовательности, в которой предполагается внедрение релиза.
    • Условия тестовой платформы должны быть максимально приближены к условиям боевой. Если приложение использует кластер из 5 memcached-серверов – подготовьте >1 сервера на тестовой платформе. Если приложение использует 1 master-сервер СУБД в режиме RW и 2 slave-сервера в режиме RO – воссоздайте полную схему репликации. Сэкономить на оборудовании для тестирования распределенных систем поможет бесплатный VMWare Server (или любой другой аналог, кроме Virtuozzo). Версии системных библиотек, ядра ОС и пр. должны также совпадать с версиями соответствующих компонент боевой платформы.
    • Нагрузочное тестирование является плавающей проблемой приемочного тестирования. Полностью воссоздать условия релиза невозможно: мы не знаем, какой точно будет нагрузка, мы можем только предполагать. Да и создавать полную копию боевой платформы накладно. Для адекватного тестирования обычно выделяют в приложении узкие места, измеряют для них максимальные значения устойчивости и аппроксимируют результаты на ожидаемые нагрузки.
    • Тестирование должно быть регрессионным, но нужно балансировать между качеством и затратами. Если внесены только косметические изменения в интерфейс, нет смысла прогонять тест-план полностью.
    • Не забудьте об откате приложения, возврат к предыдущей версии должен быть тщательно отработан.
    Переход от кандидата к релизу может занять определенное количество итераций «Кандидат – Тестирование – Изменение». В ходе цикла будут находиться новые баги, меняться требования и вноситься изменения. В конечном итоге, придется разорвать порочный круг и делать релиз. И крайне редко предрелизный отчет о тестировании оказывается на 100% завершенным (разработчики в таких случаях отмазываются приставкой beta).
    Рулил я когда-то разработкой портала о рекламе. Команде тогда пришлось выкатить ~20 кандидатов до внедрения релиза. Релиз внедрили с 10-ого раза. Итоговый отчет о тестировании был успешен на ~70%. Не самый удачный проект в моей жизни.

    К оружию

    Порядок внедрения релиза должен быть следующим:
    1. Внедряем новые версии компонент платформы. Обновляем библиотеки, сервисы и пр., при этом оставляем себе инструмент для отката до старых версий.
    2. Внедряем БД и файловое хранилище. В случае если в бою работает предыдущая версия приложения, необходимо заранее подготовить старый релиз к поддержке новой структуры хранилищ. История такая:
      • добавляем предыдущему релизу поддержку новой схемы хранения
      • внедряем измененный предыдущий релиз
      • внедряем новую структуру хранения и мигрируем данные (предыдущий релиз должен работать в старой логике с новым хранилищем)
      • внедряем новый релиз
    3. Внедряем приложение.
    4. Тестируем приложение.
    5. Откатываемся (если необходимо).
    В случае факапа откатываемся к предыдущей версии в обратном порядке:
    1. Откатываем приложение.
    2. Откатываем БД и файловое хранилище (если необходимо).
    3. Откатываем компоненты платформы (если необходимо).

    Приложение в бой

    Во-первых, приложение должно быть спроектировано таким образом, чтобы ее структура папок была отделена от файлового хранилища.
    Правильно
    /var/www/myproject/
    	/etc/
    	/lib/
    	/classes/
    	/images/
    	/templates/
    	index.php
    /var/www/userdata/
    	/images/
    	/video/
    
    Не правильно
    /var/www/myproject/
    	/etc/
    	/lib/
    	/classes/
    	/images/
    	/templates/
    	/userdata/
    		/images/
    		/video/
    	index.php
    
    Во-вторых, необходимо контролировать версии библиотек сторонних разработчиков. Чтобы быть уверенным, что в бою используется поддерживаемая версия библиотеки Zend Framework, необходимо либо включить библиотеку в структуру папок приложения (и держать ее в svn), либо представлять релиз в виде пакета (например, deb), с помощью которого проверять зависимости.

    В-третьих, многие разработчики внедряют приложение в бой обновлением из репозитория исходного кода (svn up). Сравнить такой подход можно разве что с rm –rf /. Релиз необходимо полностью извлекать из репозитория и размещать в отдельном от предыдущего релиза месте.
    Релизы размещаются в отдельных папках на боевой платформе
    user@stable:~/apps/myproject$ ls -la
    drwxr-xr-x 12 user www-data 4096 Окт 29 11:38 .
    drwxr-xr-x  5 user www-data 4096 Май 13 23:22 ..
    drwxr-xr-x  8 user www-data 4096 Окт 22 17:11 rel_0.5.1
    drwxr-xr-x  8 user www-data 4096 Окт 27 13:17 rel_0.5.1.1
    drwxr-xr-x  8 user www-data 4096 Окт 28 02:07 rel_0.5.1.2
    drwxr-xr-x  8 user www-data 4096 Окт 29 11:38 rel_0.5.2
    user@stable:~/apps/myproject$ svn co svn+ssh://user@svn.myproject.ru/myproject/tags/rel_0.5.2.1
    ...
    user@stable:~/apps/myproject$ ls -la
    drwxr-xr-x 12 user www-data 4096 Окт 29 11:38 .
    drwxr-xr-x  5 user www-data 4096 Май 13 23:22 ..
    drwxr-xr-x  8 user www-data 4096 Окт 22 17:11 rel_0.5.1
    drwxr-xr-x  8 user www-data 4096 Окт 27 13:17 rel_0.5.1.1
    drwxr-xr-x  8 user www-data 4096 Окт 28 02:07 rel_0.5.1.2
    drwxr-xr-x  8 user www-data 4096 Окт 29 11:38 rel_0.5.2
    drwxr-xr-x  8 user www-data 4096 Окт 29 12:31 rel_0.5.2.1
    
    После извлечения исходного кода проект инсталлируется (настраиваются конфиги, права, стартовые данные) и тестируется рядом с работающим релизом, для чего может использоваться отдельный виртуальный хост веб-сервера (например, www-test.myproject.ru). После прогона тест-плана, предыдущий релиз подменяется новым. Известны следующие варианты замены релизов: изменение символической ссылки, mount_null, изменение конфига веб-сервера с последующим graceful restart.
    Символической ссылкой мы переключаем проект с одного релиза на другой.
    Таким же образом можно откатится к предыдущей версии.
    user@stable:~/httpdocs/ $ ls –la
    drwxr-xr-x 3 user www-data  4096 Окт 29 11:40 .
    drwxr-xr-x 9 user www-data  4096 Окт 28 21:25 ..
    lrwxrwxrwx 1 user www-data  27 Окт 29 11:40 pro -> ../apps/myproject/rel_0.5.2
    user@stable:~/httpdocs/ $ rm pro && ln –s ../apps/myproject/rel_0.5.2.1 pro
    user@stable:~/httpdocs/ $ ls –la
    drwxr-xr-x 3 user www-data  4096 Окт 29 11:40 .
    drwxr-xr-x 9 user www-data  4096 Окт 28 21:25 ..
    lrwxrwxrwx 1 user www-data  27 Окт 30 17:12 pro -> ../apps/myproject/rel_0.5.2.1
    
    Если приложение распределенное:
    • отключаем часть бэкендов, перенаправив весь трафик с фронтов на оставшиеся рабочие
    • На отключенных бэкендах проводим локальные внедрения и тесты
    • переключаем трафик на свежие бэкенды
    • повторяем процедуру для освободившихся бэкендов
    • В результате поблочного внедрения фронтенды переключаем в нормальное состояние и распределяем нагрузку по всем бэкендам.
    Чем больше серверов задействовано и чем сложнее структура приложения, тем больше потребуется инструментов автоматизации и контроля внедрения. Однако не стоит забывать любимое правило футурологов: не доверяйте роботам – их создавали люди, которым свойственно ошибаться.
    P.S. Если хватит сил закончить повествование, ждите вторую часть о прелестях LiquiBase, подводных камнях rsync и миграции файловых хранилищ.
    P.P.S. В ходе переписки с одним из хабраюзеров сформулировалось: главным в этом информационном обращении является не навязывание своих рекомендаций, а то что я заставляю человека задуматься о проблемах, которые могут возникнуть в своей конкретной ситуации. Общие рекомендации на*^& никому не нужны. В итоге, каждый делает по-своему. И это правильно. Потому что каждый проект уникален.

    Similar posts

    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More
    Ads

    Comments 43

      +4
      Все доступно и понятно, спасибо!
        0
        Вы говорите как делать, но не говорите почему выбрали именно этот способ. Такие Инструкции, на мой взгляд, понятны только тем, кто это все уже давно знает и применяет на практике.
          +5
          Я делюсь с хабрасообществом лучшей практикой из своего личного опыта. Для того чтобы рассказать все в деталях, придется написать книгу =) Если есть вопросы «почему» — задавайте в комментах или в хабрапочте.
          0
          А вы не могли бы написать обзор инструментов для операций внедрения, отката и, возможно, тестирования?
            +2
            Для внедрения/отката подойдет Apache Ant, CruiseControl не зависимо от того на чем разрабатываете. Автоматизация тестирования — любой удобный вам Unit-фреймворк, Selenium (ацкая хрень, сжирает кучу времени). Это что первое приходит в голову.

            А вообще, специализированные инструменты для этих операций нужно использовать, если у вас действительно большой проект и много участников. Для простых проектов достаточно ручных операций с svn и стандартных системных утилит.
              0
              Во время ручных операций иногда происходят достаточно серьезные ошибки, поэтому хочется более ли менее автоматизированную систему. Спасибо.
                +2
                кстати селениум не такой уж ацкий ) дело в том, что сам по себе он является лишь фреймворком, и для эффективного его использования на его основе необходимо создавать специальный отточенный инструмент, направленнный на скорость разработки тестов. готовых решений нет, на что-то более-менее близкое похож bromine, но он крив, и развивать его будут, судя по всему, очень очень медленно
                  0
                  Selenium, надо отметить — это функциональное тестирование.
                  А CruiseControl.NET мы используем для .NET. То же самое касается NAnt и NCover, у которых есть аналоги — Ant и Cover.
                  Кстати, еще популярным CI-сервером становится TeamCity в последнее время…
                0
                Спасибо!
                  +4
                  их реализация не должна отнимать больше 20% рабочего времени. Разрабатывать через тестирование – крайняя степень расточительства.

                  очень спорное утверждение, думаю стоит остановиться на «Разработка автотестов не всегда оправдана.»
                    +1
                    Останавливайтесь на здоровье=) А я, пожалуй, не буду.
                      +3
                      Все зависит от масштабов проекта. Если вы пишете сложную систему с навороченной бизнес-логикой и используете паттерн MVC (возможно MVP или нечто аналогично заранее ориентированное на юнит-тесты), то Test Driven Development сэкономит вам кучу времени, нервов и, как следствие, денег на разработку и тестирование. Если код покрыт тестами хотя бы на 80-90% и подключена система автоматического тестирования каждой ревизии проекта в репозитории, практически любая ошибка в бизнес-логике отлавливается на протяжении часа.
                        0
                        А не подскажете где бы подробней, с примерами посмотреть про автоматическое тестирование применительно к разработке web-приложений? Поискал — всюду общие слова, и ноль конкретики, типа «пишите набор тестов и будьте счастливы». Хотелось бы посмотреть поближе как это делается.
                          +2
                          Вот статья на тему:
                          cylib.iit.nau.edu.ua/Books/ComputerScience/PhilosophyProblem/xprogramming.ru/Articles/LoveUT.html
                          Вкратце, тестировать нужно каждую функцию проекта (не в смысле «метод», а в смысле «действие»). К примеру мне приходилось работать с системой документооборота, в которой обрабатывались документы типа таможенных деклараций. Для декларации существовала определенная иерархия состояний, которые определяли набор действий, которые можно совершать над декларацией. Например, в состоянии Created автор декларации может вносить изменения в ее наполенение, но декларация не отображается в списке на проверку и ее нельзя заапрувить. В то же время, в состоянии Finalized ее можно заапрувить, но редактировать нельзя. Собственно для проверки соответствия состояний и разрешенных действий был написан юнит тест, который падал, если кто-либо внес изменения в вышеописанную логику.
                          На примере хабра можно было бы написать тест, который проверяет, что может делать юзер с отрицательным значением кармы, тест, который проверяет, скрывается ли сильно заминусованый коментарий и т. д. и т. п.
                            0
                            спасибо, посмотрю
                        +1
                        sun и microsoft проводили исследования, которые показали что замедляя на старте технология позволяет ускорить процесс разработки в целом. навскидку насколько быстрее становится разработка при разработке через тестирование, можете погуглить. если написание тестов займёт >20% процентов времени, то во сколько выльется поиск бага в нетестируемом коде. другое дело что необязательно облаживать тестами обсолютно каждый пук.
                          0
                          Вот именно! 20% — это просто провокационное число, которое заставит задуматься о затратах.
                            0
                            Примерно так же, как и любое другое число, например, 42. Для меня TDD ценно хотя бы тем, что я не боюсь что-то сломать. А уж как тут эти процентики мерять вообще непонятно.
                              +1
                              Это был сарказм, 20% получено из практики — когда-то потребовалась это число, теперь пользуюсь. Измерялось примерно так: взял старые планы (свои и чужие), оценил объем плановых работ «Разработка автотестов», оценил потраченные по факту. Убрал те проекты, которые не смогли поддерживать изначальное покрытие тестами. Убрал те проекты, чьи качество существенно снизилось в ходе эксплуатации. Остались те, у которых соотношение разработки тестов к разработке функционала был 15%-25%. Конечно, в лоб это число применять нельзя. Нужно рассматривать каждый случай.
                                0
                                Спасибо. Вы бы это в статье написали ;)

                                ЗЫ: Только это, ИМХО, средняя температура по больнице.
                      0
                      Приложение каждого разработчика должно использовать персональные БД и файловые хранилища.


                      Про файлы может вы и правы, а вот про базу я бы не согласился.
                      Если каждый будет работать со своей базой — замучается потом синхронизировать изменения. Один там индекс прописал, второй там.

                      В Рельсах очень удобно работать с одной базой, миграции решают проблемы с синхронизацией на лету.
                      Нет рассинхронизации структуры и данных, меньше времени на слияние.
                      Для пхп аналогичных решений пока не встречал.
                        +1
                        Посмотрите LiquiBase, вам понравится
                          0
                          О, это как раз то, чего я давно уже ищу!
                          /me пошел писать шел для cakephp
                          0
                          У нас на прошлом проекте проблема решалась апгрейд скриптами для БД, которые комитились в репозиторий. Если разработчик решал изменить структуру БД, он писал SQL запрос, который меняет базу, ложил в соответствующую папку проекта под именем типа 20080930.001.sql (имена файлов в таком формате, чтоб скрипты потом выполнялись в порядке добавления в репозиторий). После свн апдейта было достаточно запустить скрипт AfterUpdate.cmd, который запускал все новые скрипты и обновлял локальную БД. Скрипты потом использовались и при деплое новой версии проекта заказчикам.
                            +1
                            Посмотрите LiquiBase, вам понравится
                            0
                            В symfony вся Схема базы данных хранится в файле schema.yml или schema.xml, Изменения БД очень просто отслеживать через SVN.
                            Плагин www.symfony-project.org/plugins/sfPropelSqlDiffPlugin генерирует ALTER TABLE автоматически.

                            Также можно использовать Миграции Doctrine
                            www.doctrine-project.org/blog/new-to-migrations-in-1-1
                            +4
                            > user@stable:~/httpdocs/ $ rm pro && ln –s ../apps/myproject/rel_0.5.2.1 pro

                            Непрофессионально: если между двумя действиями случится запрос — юзер увидит ошибку. Надо переименовывать symlink, это атомарно.
                              +1
                              Спасибо за замечание. Но суть я надеюсь все уловили.
                              +1
                              вы пренебрегаете необходимостью тестов — значит не работали с живыми деньгами, которые приносят пользователи и тратят на вашем сервисе. если работали — горе вам и вашим проектам. кроме того, release candidate и проведение приемочного тестирования людьми на любую типографическую ошибку — это из разряда фантастики. для таких ошибок должен существовать механизм quick-fix. он же поможет, когда сервер обваливается и правки делаются на живой релизной машине (потому что пока вы развернете еще одну версию, проверите все и запустите ее — у вас может не остаться ни одного пользователя).

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

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

                              поэтому, перед выкладкой новой версии сервис полностью останавливается (с показом maintenance mode — пользователи нормально относятся к нему, а вот к ошибкам — не очень), все данные и базы бэкапятся, также бэкапятся библиотеки (в том числе и системные, от которых проект зависит) и только тогда начинаем выкатывать новую версию проекта.

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

                              «…проект инсталлируется (настраиваются конфиги, права, стартовые данные) и тестируется рядом с работающим релизом…» — просто чудовищно. все конфигурации, права, стартовые данные обязаны уже быть в файлах инсталляции боевого сервера. если вы не можете поднять новый сервер одной командой или у вас есть на сервере несохраненная конфигурация — ждите беды, когда важный файлик потрется, которого у вас не было нигде, кроме как в рабочей инсталляции.
                                +2
                                Ну вот правда, не хотелось вступать в полемику, максимум ответить на вопросы по своей точке зрения. Но тут человек старался, столько много написал про мое разоблачение… Придется тоже что-нибудь ответить.

                                вы пренебрегаете необходимостью тестов

                                Я считаю, что тесты — необходимость. Не знаю, где вы вычитали что я ими пренебрегаю. Тесты позволяют разработчику сдать проект в приемочное тестирование в нормальном состоянии. Делать же оценку качества по автотестам нельзя. Говоря о верхней планке затрат, я затрагиваю две проблемы. Первая — тесты, это тоже код, который пишут люди, а значит оттуда растут баги. Вторая — в своем стремлении создать идеальную систему разработчики настолько тверды, что готовы потратить громадное количество времени на покрытие кода тестами. Но реальная потребность покрытия тестами возникает только в важных и серьезных местах приложения. Менеджеры, которые вписывают громадные затраты на работы класса «Разработка unit-тестов», либо не умеют считать деньги, либо доверчивые идиоты, либо искусственно завышают бюджет.

                                кроме того, release candidate и проведение приемочного тестирования людьми на любую типографическую ошибку

                                Говорите какие-то глупости, о чем вообще не было написано.

                                для таких ошибок должен существовать механизм quick-fix

                                Чтобы делать quick-fix, нужно еще найти корень зла, на что уйдет больше времени, чем сделать мгновенный откат до предыдущей версии — переключить контекст веб-сервера на предыдущий релиз.

                                никогда нельзя выкатывать и проверять инсталляцию на машину

                                Гораздо круче все застопить, запустить новый процесс и посмотреть что получится — заведется или не заведется?

                                перед выкладкой новой версии сервис полностью останавливается

                                Расскажите об этом ребятам из любого высоконагруженного проекта (Яндекс, Рамблер, РБК). Подсчитывать бабло и смеятся будем все вместе.

                                пользовательские файлы обязаны быть частью текущей версии и частью директории проекта

                                Расскажите об этом ребятам из фотофайла или любого видеосервиса. Будет в два раза смешней!

                                Как- то так. Про остальное глупо писать — человек просто не понял сути. Либо я дал слишком мало информации о приемах.
                                  +1
                                  соглашусь, про тесты не совсем внимательно прочитал

                                  «Говорите какие-то глупости, о чем вообще не было написано.»
                                  «Релиз-кандидат – это конечный монолитный продукт, в который нельзя вносить изменения. Если необходимо исправить ошибки, доработать функционал – необходимо начинать с начала и делать нового кандидата.»
                                  «Чтобы делать quick-fix, нужно еще найти корень зла, на что уйдет больше времени, чем сделать мгновенный откат до предыдущей версии — переключить контекст веб-сервера на предыдущий релиз.»

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

                                  «Гораздо круче все застопить, запустить новый процесс и посмотреть что получится — заведется или не заведется?»

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

                                  «Расскажите об этом ребятам из любого высоконагруженного проекта (Яндекс, Рамблер, РБК). Подсчитывать бабло и смеятся будем все вместе.»

                                  да, давайте посмеемся. я работал в яндексе и выкладывал код на главную страницу яндекса. яндекс, рбк, фотофайл и тому подобные сервисы сильно вырождены и сегментированы — они выполняют одну функцию и на нее заточены. большинство сетевых мультисервисов имеют в своем основании сразу множество функций. и до тех пор, пока сервис не вырождается в функцию, имеет смысл позаботиться о сохранности (и копировании) данных.
                                    0
                                    Реально, в этом то и проблема, что проекты медиа-холдингов жутко сегментированы. Зачастую, внедрения сателлитных систем, переплетенных со всем наборов веб-проектов, происходят самостоятельно. Именно поэтому необходимы тесты на интеграцию при внедрении, именно поэтому цена работоспособности маленького субпроекта Яндекса выше, чем цена работоспособности модуля нишевого веб-проекта.
                                +2
                                > Разработка автотестов не всегда оправдана: их реализация не должна отнимать больше 20% рабочего времени. Разрабатывать через тестирование – крайняя степень расточительства.

                                Можно подробнее, почему TDD — это крайняя степень расточительства?
                                  0
                                  Здесь habrahabr.ru/blogs/webdev/43643/#comment_1084963 я ответил человеку про проблемы модульного тестирования и почему я предлагаю рамки.

                                  За свою практику я манагерил 3 веб-проекта в соответствии с TDD — все провалились по одной и той же причине: на сопровождение (актуализацию) пространства тестов требовалось слишком много времени. В итоге, все 3 проекта разного размера (Java, Java, PHP), сделанные разными командами, перешли в классическую схему — частично покрытый тестами код. Веб-проекты требуют слишком частых и значительных изменений =(

                                  И хотелось бы предостеречь от неправильных выводов — все вышесказанное относится только к веб-проектам. Я сам — экс-фанат методологии TDD. Возможно, TDD оправдан в разработке банковским систем или систем автоматического управления поездами метро. Но я лично пока не нашел TDD практического применения.
                                  +2
                                  Шикарно, спасибо большое. Мне, как чайнику в этих делах, статья очень помогла разобраться с вопросом.
                                    +1
                                    Вас также хочется предостеречь. Описанное в хабратопике — не панацея. Это всего лишь срез наилучшего, что я видел за 8 лет в разработке веб-проектов и применял на практике. Импровизируйте, делайте свои уникальные солюшены для своих проектов. Если у вас есть сомнения по поводу написанного — это даже лучше!
                                      +1
                                      Ок, ясно.
                                    +2
                                    по поводу «необходимо контролировать версии библиотек сторонних разработчиков. Чтобы быть уверенным, что в бою используется поддерживаемая версия библиотеки Zend Framework, необходимо либо включить библиотеку в структуру папок приложения (и держать ее в svn)»…

                                    Рекомендую к прочтению тем, кто использует Subversion: Externals definitions. Цитата: «An externals definition is a mapping of a local directory to the URL—and possibly a particular revision—of a versioned resource»
                                      0
                                      спасибо за статью, очень полезно и доступно!
                                        0
                                        Классная статья. Только вот несходяться ваши взгляды с опытом легендарных гуру (Фаулер, Поль Дюваль), насчет непрерывной интеграции и разработкой путем тестирования
                                          0
                                          Это нормально, ибо сферы разные. Веб очень часто меняется, тут при 100% покрытии всплывает то, что тесты, по сути, дублируют бизнес логику. Например тестирование контроллеров и экшенов. У нас выработалось четкое правило — если хочешь протестировать (не уверен + сложно), сделай сервис/хэлпер/еще-что-то-там.
                                          0
                                          Что автор имеет против Virtuozzo?
                                            0
                                            а кнопу «в избранное» создатели сайта сделать забыли что-ли?

                                            Only users with full accounts can post comments. Log in, please.