пятница, 11 апреля 2008 г.

О Continuous Integration (ci)

Вытаил время для очередного топика. На этот раз захотел написать о таком понятии как Continuous Integration, ну или просто CI. Для тех кто не знает что это такое, то читаем в Wiki . Прочитав можно сразу понять, что понятие ci было впервые озвучено многоуважаемыми Фаулером и Беком в качестве набора базовых практик которые позволяют команде наиболее быстро получать фидбек по работе софта.
Не буду затрагивать все практики, а обращу внимание на 1, а именно "Make your build self-testing". Обычно под этой практикой имеют в виду TDD и чаще всего юнит тестирование. Мы же в своей команде расширили это понятие и кроме юнит тестирования прикрутили собственные автоматизированные ГУИ тесты. Такого рода опыт сразу облегчил жизнь как нам так и девелоперам. Реакция CI происходит по разному но в основном по проделанному коммиту конечно же...

Каковы плюсы этого подхода?
1) Девелоперы получают дополнительный фидбек в виде результатов гуи(функциональных) тестов
2) Команде QA облегчается жизнь так, что не надо проводить тесты у себя на предмет не похерилась ли уже имеющиеся логика, а сконцентрироваться на тестировании именно новой задачи.
Все конечно хорошо но есть и минусы:
1) Гуи тесты должны быть 100% рабочими и стабильными. Те кто хоть раз пытались написать автоматизированные тесты меня поймут, что это не так то и легко
2) Если коммит был предназначен на то, чтобы поменять имеющуюся логику, билд валиться. Что многих бесит, да и меня тоже.
3) Если софт очень большой, то покрыть всё гуи тестами может быть и возможно, но они будут проходить очень долго и муторно.
Минусы конечно же весомые, но советовал бы попробывать всем, потому что по нашему опыту работать становится все таки легче и удобней. По поводу того, как все это построить и настроить много пишет Ромка, поэтому его боянить не буду. Готового софта для построения CI более чем достаточно. Для себя же мы выбрали связку Atlassian Bamboo в связке в основном с Ant-ом.

Ну в общем то для начала думаю хватит.