>>Тестирование делается для определения готовности перехода проекта на новую фазу, то есть деплоймента.
И да, и нет. В статье слово деплоймент упоминается 5 раз — но нигде не написано, что сам по себе деплоймент является целью CI. Тесты же проверяют работоспособность функциональности и отсутствие регресионных багов — независимо, собираетесь вы деплоить именно этот билд, или нет.
И ещё о Senior-ах. ИМХО, Senior должен также постоянно учится. И если ему представляется случай улучшить качество собственного кода — почему нет? Двое моих друзей, не зарегистрированных пока Хабре, с прочли эту статью, ещё до публикации здесь. Оба синьоры, оба ниразу не работали с CI. Один сказал — интересно, при случае попробую. Второй — купил эту книгу.
С моей стороны — друге ИМХО: чисто не там где убирают, а где не сорят. Если с самого начала на проекте установлена политика отсутствия предупреждений и отформатированного кода — поддержка не занимает много времени разработчиков. С другой стороны — собственно предупреждения — они ж неспроста… Каждое предупреждение — потенциальная ошибка.
Я, как ведущий программист на проекте, хочу делать качественный код, независимо от того, что мне сказал Product Manager. Мне неприятно (психологически) работать с кодом, который пестрит предупреждениями и подсказками. Соответственно нужно выбрать здоровый компромис между бюрократией ти качеством.
Я не пытался никого обидить, и если кто-то принял это на свой счет — прошу прощения.
А теперь по сути критики. Простите, но я не понимаю, каким образом может корелировать постоянное тестирование с деплойментом. Если у вас на проекте есть тесты — то чем станет хуже если они будут запускатся на каждом коммите, указывая на набор изменений который привел к поломкам? Нет, это не серебрянная пуля. Конечно, требования и процессы разные. И возмножно где-то по процессу даже допустимо бинарники хранить в svn…
И ещё раз относительно senior-прогамистов. К сожалению (или к счастью) далеко не все мы работаем в огромных компаниях на больших проектах, где есть build engineer или configuration manager. Зачастую спасение утопающих — дело рук самих утопающих. И senior програмист как минимум должен иметь представление о CI на уровне пользователя. Мой к примеру тех-директор не поймет, если я приду к нему и скажу: тестер не получит билдов пока на проекте (из 5 человек) не будет билд-инженера. А коммитить бинарники в svn — простите, религия не позволяет.
К сожалению я не очень в курсе относительно того, как CI реализуют на проектах с интерпретируемыми языками. Как минимум прогонка unit-тестов при каждом коммите — вещь очень позитивная. Ну и наверное какая-нибудь проверка синтаксиса должна быть. Относительно деплоймента на тестовый сервер — не уверен, что это хорошая идея обновлять его по каждому коммиту. У меня на предыдущих проектах к примеру принято было на каждом билде деплоить на сервер разработчиков, деплоймент на тест-сервер совершался асинхронно самим тестером через тот же тимсити.
можно… хотя по-моему не следует смешивать билд-сервер с сорц-контролом. Кроме того, специфический инструмент во многом лучше позволяет наблюдать за процессом. Из плюсов вашего варианта — нерабочий код никогда не попадет в сорц-контрол. С другой стороны тот же TeamCity позволяет гонять персональные билды — и коммитить в случае успеха, что дает схожий результат.
Позвольте не согласится. Во первых — не для любого веб-проекта, а вообще практически для любого проекта. Во вторых — пример на .Net, но схема остается та же. У вас проект на джаве с антом? Изменяем раннер, и все остальное справедливо.
Ну зато им удобно клиентам релизы сдавать… Клиенты тоже svn-у обучены. Где свежая версия?.. Да там, в svn возьми.
Вот сейчас pm-у мозги промыл — помаленько и остальные субпроекты под TeamCity перетаскивает.
Скорее нет, чем да. Да — потому что позволяет Ant запускать, но в то же время не заменяет его. Нет — потому что (если на пальцах и в двух словах) работает постоянно, в режиме сервиса/демона и следит за изменениями в Source Control. Если есть изменения — запускает Ant (ну или Maven, cmd или что там у вас).
Я не волшебник, я только учусь… Поэтому наверное и получилось несколько сумбурно. В любом случае спасибо. В дальнейшем тему буду развивать, так как она «о наболевшем». В плане ещё как минимум статья о интеграциях БД. Если будет спрос (ваш комент наберет плюсов) — сделаю в «картинках» и примерах.
Относительно терминов: вводя каждый термин старался давать простое определение, но может где что-то пропустил… Со стороны лучше видно, поэтому: какие именно термины непонятны?
Поездил и я в свое время. В большинстве все-таки впечатления позитивные. Но и неприятные казусы были. К примеру меня, в те времена студента прикладной математики, одинажды случайно отправили на всеукраинскую олимпиаду по криптологии… Просто потому-что кто-то у нас в универе в верхах видать решил что один черт — программирование, криптология. Я чесно брыкался — да не помогло, вместо Тернополя пришлось ехать в Харьков. Пару умных книжиц почитал, RSA от Аль-Гамаля уже отличал. Приехал — а там в заданиях сплошные элиптические группы, коих я в глаза не видел. Сдал листочек с единственной фразой — «Простите, я ошибся олимпиадой.»
Получил предпоследнее место — кто-то сдал совсем чистый листок)
И да, и нет. В статье слово деплоймент упоминается 5 раз — но нигде не написано, что сам по себе деплоймент является целью CI. Тесты же проверяют работоспособность функциональности и отсутствие регресионных багов — независимо, собираетесь вы деплоить именно этот билд, или нет.
И ещё о Senior-ах. ИМХО, Senior должен также постоянно учится. И если ему представляется случай улучшить качество собственного кода — почему нет? Двое моих друзей, не зарегистрированных пока Хабре, с прочли эту статью, ещё до публикации здесь. Оба синьоры, оба ниразу не работали с CI. Один сказал — интересно, при случае попробую. Второй — купил эту книгу.
Я, как ведущий программист на проекте, хочу делать качественный код, независимо от того, что мне сказал Product Manager. Мне неприятно (психологически) работать с кодом, который пестрит предупреждениями и подсказками. Соответственно нужно выбрать здоровый компромис между бюрократией ти качеством.
А теперь по сути критики. Простите, но я не понимаю, каким образом может корелировать постоянное тестирование с деплойментом. Если у вас на проекте есть тесты — то чем станет хуже если они будут запускатся на каждом коммите, указывая на набор изменений который привел к поломкам? Нет, это не серебрянная пуля. Конечно, требования и процессы разные. И возмножно где-то по процессу даже допустимо бинарники хранить в svn…
И ещё раз относительно senior-прогамистов. К сожалению (или к счастью) далеко не все мы работаем в огромных компаниях на больших проектах, где есть build engineer или configuration manager. Зачастую спасение утопающих — дело рук самих утопающих. И senior програмист как минимум должен иметь представление о CI на уровне пользователя. Мой к примеру тех-директор не поймет, если я приду к нему и скажу: тестер не получит билдов пока на проекте (из 5 человек) не будет билд-инженера. А коммитить бинарники в svn — простите, религия не позволяет.
Подзаголовков — сейчас перечитаю — добавлю.
Вот сейчас pm-у мозги промыл — помаленько и остальные субпроекты под TeamCity перетаскивает.
Относительно терминов: вводя каждый термин старался давать простое определение, но может где что-то пропустил… Со стороны лучше видно, поэтому: какие именно термины непонятны?
Получил предпоследнее место — кто-то сдал совсем чистый листок)