• Like
  • Save

Loading…

Flash Player 9 (or above) is needed to view presentations.
We have detected that you do not have it on your computer. To install it, go here.

Continuous Integration как инструмент управления рисками при разработке программного обеспечения

  • 540 views
Uploaded on

 

More in: Education
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
540
On Slideshare
0
From Embeds
0
Number of Embeds
1

Actions

Shares
Downloads
0
Comments
0
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. Continuous Integration как инструмент управления рисками при разработке программного обеспеченияСубота, 24 грудня 2011 р.
  • 2. Что нужно для производства качественного ПО?Субота, 24 грудня 2011 р.
  • 3. Continuous integration утверждает: Следить за изменениями в коде Строить продукт для каждого изменения Оценивать качество кода Публиковать результатыСубота, 24 грудня 2011 р.
  • 4. Можете ли вы ответить: что изменилось в вашем проекте вчера? остался ли проект работоспособным? изменились ли показатели качества? чем вы можете подтвердить качество?Субота, 24 грудня 2011 р.
  • 5. Затрудняетесь ответить? ДА тогда ваш проект подвержен рискамСубота, 24 грудня 2011 р.
  • 6. Каким рискам? Заказчик захочет получить ответы на такие же вопросы: “что?”, “где?”, “когда?” и “чем докажете?” Заказчик захочет продать ПО и привлечет внешних аудиторов, которые тоже будут спрашивать. Вы просто утратите контроль над разработкой, появиться масса ошибок и тогда см. п. #1Субота, 24 грудня 2011 р.
  • 7. Вы успокаиваете себя: Мы очень аккуратно пишем код Наши пользователи - лучшие тестеры У нас этого не произойдетСубота, 24 грудня 2011 р.
  • 8. Пока вы читаете этот слайд это уже происходитСубота, 24 грудня 2011 р.
  • 9. Диалоги в курилкеСубота, 24 грудня 2011 р.
  • 10. М. Мы добавили новых разработчиков, но скорость разработки не выросла, как ожидалось. ТL. Мне все трудней отслеживать дублирование кода. Разработчики жалуются на несоблюдение стандартов. М. Я трачу много времени на объяснение заказчику причин сбоев. Почему так много? ТL. Мы просто утратили контроль над проектом.Субота, 24 грудня 2011 р.
  • 11. “Хьюстон, у нас проблема!”(Appolo13)Субота, 24 грудня 2011 р.
  • 12. Что нам делать? мы не успеваем... - автоматизируйте у всех разные результаты... - исключите повторы и централизируйте мы договорились, но все забыли... - документируйте я говорил, но не все были в офисе - используйте e-mail, sms, голубиную почтуСубота, 24 грудня 2011 р.
  • 13. Как это использовать на практике? Легко. Можно сразу все, но лучше поэтапноСубота, 24 грудня 2011 р.
  • 14. Как следить за изменениями в коде? Используйте систему контроля версийСубота, 24 грудня 2011 р.
  • 15. Как быть с остальным? Централизуйте ... Положите скрипт построения БД в VCS рядом с кодом, который ее использует Поступите так же с остальными частями системы Продукт - это не только код.Субота, 24 грудня 2011 р.
  • 16. Как оценить качество кода? Architecture Complexity Duplications Comments Unit testing Coding rules Test coverage Potential bugsСубота, 24 грудня 2011 р.
  • 17. Мы пытаемся следить за качеством, но анализ вызывает много споров. Напряжение в команде растет Автоматизируйте ... Используйте инструменты статического и динамического анализа кода На машину нельзя обижатьсяСубота, 24 грудня 2011 р.
  • 18. Процессов слышком много. На все не хватает рук и времени. Автоматизируйте... Уменьшите количество повторяемых процессов Объедините все процессы в единый скрипт сборкиСубота, 24 грудня 2011 р.
  • 19. Наши тестеры не справляются с проверкой старого и нового функционала Автоматизируйте... Напишите автоматические тесты Проводите регрессионное тестированиеСубота, 24 грудня 2011 р.
  • 20. Мы слишком поздно узнаем об ошибках. Уменьшите время прохождения построений Прогоняйте все тесты во время построения Передавайте код в хранилище часто Не передавайте в хранилище сбойный кодСубота, 24 грудня 2011 р.
  • 21. Следить за изменениями слишком сложно. Результаты сборки у всех разные. Выделите отдельную машину для сборки построений Настройте на ней сервер CIСубота, 24 грудня 2011 р.
  • 22. Мы настроили сервер CI, но никто туда не смотрит. Отчеты слишком избыточны. Настройте уведомления о результатах построения Доставляйте отчеты с информацией в зависимости от роли в проекте Комбинируйте и следите за каналами доставкиСубота, 24 грудня 2011 р.
  • 23. Мы не представляем, как устроено наше ПО. Пока мы уточняем - информация устаревает. Создайте необходимый минимум спецификаций и схем Автоматизируйте и централизуйте всю возможную документациюСубота, 24 грудня 2011 р.
  • 24. Мы подумали и решили не использовать CI Слишком много дополнительной работы Многое придется изменить в рабочем процессе Затраты на ПО и оборудование Разработчики и так должны это делатьСубота, 24 грудня 2011 р.
  • 25. CI поможет вам: автоматизировать и контролировать процессы, которые вы и так делаете вручную снизить затраты на поиск и устранение проблем поэтапно упорядочить весь процесс сборкиСубота, 24 грудня 2011 р.
  • 26. CI снижает риск: потери контроля над проектом отсутствия работоспособного приложения создания некачественного ПОСубота, 24 грудня 2011 р.
  • 27. Посоветуйте комплекс для CI Jenkins + Sonar http://jenkins-ci.org/ http://www.sonarsource.org/Субота, 24 грудня 2011 р.
  • 28. У вас остались вопросы? ЗадавайтеСубота, 24 грудня 2011 р.
  • 29. Спасибо за внимание Roman V. Babenko, XPDaysUA, 2011 homepage: romanvbabenko.com e-mail: romanvbabenko@gmail.comСубота, 24 грудня 2011 р.