Недавно улучшили процесс деплоя как на сторону заказчика, так и себе. Честно говоря очень обидно, что не доперли до этого сразу но все же. Принцип следующий:
Я уже писал в предыдущем посте, что мы используем Bamboo и ant в качестве средства для сборки билда и прогонки имеющихся ГУИ и юнит тестов. Так вот в Bamboo имеется такая фича как "artifacts", которая в принципе была сделана разработчиками из atlassian для хранения каких то собственных файлов после каждой попытки билда. Т.е. каждый конкретный произошедший билд имел бы какие то собственные к примеру сторонние логи или еще какую нить белеберду на вкус и цвет самого составителя билда.
И тут возникла идея для того, чтобы все qa в команде всегда имели последний валидный билд на руках, просто хранить сам билд в артифактах. Т.е. апдейт из репозитория, дальнейшая компиляция, компановка, прогон тестов и т.д. ложиться на интеграционку и в конце туннеля в артифакты суются уже готовые билды. К тому уже они имеют собственную хранящуюся историю. Говоря простым примером, то в классическом случае когда заказчик говорит "дай мне щас билд вот с этим функционалом", вы просто отправляете линку на билд в Bamboo с последним нормально оттестенным и считающимся стабильным номером билда.
Показаны сообщения с ярлыком ci. Показать все сообщения
Показаны сообщения с ярлыком ci. Показать все сообщения
четверг, 8 мая 2008 г.
пятница, 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-ом.
Ну в общем то для начала думаю хватит.
Не буду затрагивать все практики, а обращу внимание на 1, а именно "Make your build self-testing". Обычно под этой практикой имеют в виду TDD и чаще всего юнит тестирование. Мы же в своей команде расширили это понятие и кроме юнит тестирования прикрутили собственные автоматизированные ГУИ тесты. Такого рода опыт сразу облегчил жизнь как нам так и девелоперам. Реакция CI происходит по разному но в основном по проделанному коммиту конечно же...
Каковы плюсы этого подхода?
1) Девелоперы получают дополнительный фидбек в виде результатов гуи(функциональных) тестов
2) Команде QA облегчается жизнь так, что не надо проводить тесты у себя на предмет не похерилась ли уже имеющиеся логика, а сконцентрироваться на тестировании именно новой задачи.
Все конечно хорошо но есть и минусы:
1) Гуи тесты должны быть 100% рабочими и стабильными. Те кто хоть раз пытались написать автоматизированные тесты меня поймут, что это не так то и легко
2) Если коммит был предназначен на то, чтобы поменять имеющуюся логику, билд валиться. Что многих бесит, да и меня тоже.
3) Если софт очень большой, то покрыть всё гуи тестами может быть и возможно, но они будут проходить очень долго и муторно.
Минусы конечно же весомые, но советовал бы попробывать всем, потому что по нашему опыту работать становится все таки легче и удобней. По поводу того, как все это построить и настроить много пишет Ромка, поэтому его боянить не буду. Готового софта для построения CI более чем достаточно. Для себя же мы выбрали связку Atlassian Bamboo в связке в основном с Ant-ом.
Ну в общем то для начала думаю хватит.
Подписаться на:
Сообщения (Atom)