Continuous integration (d.atanasov)

663 views

Published on

Published in: Technology, News & Politics
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
663
On SlideShare
0
From Embeds
0
Number of Embeds
3
Actions
Shares
0
Downloads
4
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide
  • Изброи tools за всеки тип тестове – Junit, TestNG, Selenium, WebLoad, Apache Jmeter, OWASP Web Scarab
  • Continuous integration (d.atanasov)

    1. 1. <ul><li>Или как да настъпваме по- малко мотики </li></ul>Continuous Integration (CI, Sonar и TDD)
    2. 2. Защо писането на софтуер е трудно ? <ul><li>Бизнесът е сложен </li></ul><ul><li>Изискванията се променят често </li></ul><ul><li>Клиентът не знае какво иска </li></ul><ul><li>Всичко трябва да стане ASAP </li></ul>
    3. 3. Как можем да подобрим ситуацията <ul><li>Наемаме още хора </li></ul><ul><li>Намаляваме обхвата на проекта </li></ul><ul><li>Променяме методологията на работа </li></ul>
    4. 4. Какво е CI <ul><li>Обикновено програмистите работят така: </li></ul><ul><li>Разработчикът пише приложение </li></ul><ul><li>QA тества приложението (може би) </li></ul><ul><li>Приложението отива при клиента </li></ul><ul><li>И ... </li></ul>
    5. 5. Ядосан клиент 
    6. 6. Как работим при CI <ul><li>Програмистът разработва част от приложението </li></ul><ul><li>Програмистът разработва тест за кода си </li></ul><ul><li>Кодът отива в Система за управление на сорса (версиите) </li></ul><ul><li>Билд сървърът взема кода и пуска тестове срещу него </li></ul><ul><li>При проблем се изпраща съобщение до програмиста / мениджъра </li></ul><ul><li>Отиваме на стъпка 1 </li></ul><ul><li>Ако всичко е Ок, отиваме да пием бира </li></ul>
    7. 7. <ul><li>? </li></ul><ul><li>Защо да си правим труда </li></ul>
    8. 8. Отговорът <ul><li>CI предполага подобряване гранулярността на задачите </li></ul><ul><li>CI ни задължава да имаме достатъчно пълни и работещи тестове, независимо от промените на клиента </li></ul><ul><li>CI позволява на разработчика/мениджъра да е сигурен в своя продукт </li></ul><ul><li>И в крайна сметка понеже софтуерът ни работи имаме и ... </li></ul>
    9. 9. Щастлив клиент 
    10. 10. Архитектура на CI
    11. 11. Какво включва билда <ul><li>Сорс код </li></ul><ul><li>Библиотеки </li></ul><ul><li>Скриптове за БД </li></ul><ul><li>Тестове и тестови скриптове </li></ul><ul><li>Скриптове за билдване </li></ul><ul><li>Файлове с настройки и др. </li></ul><ul><li>Всичко се пази във VCS (без библиотеките) </li></ul>
    12. 12. Характеристики на CI билда <ul><li>Билдът е напълно автоматичен </li></ul><ul><li>Билдът винаги взема код от VCS </li></ul><ul><li>Изходът (освен при компилационни грешки) винаги е изпълним код </li></ul><ul><li>Информацията относно състоянието на билда се изпраща на заинтересованите страни </li></ul>
    13. 13. Тестове изпълнявани от CI <ul><li>Unit тест – тества малки парчета от кода със специфична функционалност </li></ul><ul><li>Integration тест – проверява работата на различните компоненти заедно </li></ul><ul><li>Системен (функционален) тест – тества изцяло функционалността на системата (най-често през UI) </li></ul><ul><li>Load (Stress) тест – проверява държанието на системата при различни натоварвания </li></ul><ul><li>Security тест – анализира приложението за дупки в сигурността </li></ul>
    14. 14. Статичен анализ на кода <ul><li>CI може лесно да изпълнява проверка за честно срещани грешки, излишна сложност и т.н. </li></ul><ul><li>Инструменти: </li></ul><ul><li>CodePro AnalytiX </li></ul><ul><li>FindBugs </li></ul><ul><li>Checkstyle </li></ul><ul><li>Cobertura </li></ul><ul><li>Sonar </li></ul>
    15. 15. Какво още ни дава CI <ul><li>Автоматичен deployment на кода </li></ul><ul><li>CI на базата от данни </li></ul><ul><li>Обратна връзка – IM, Email, SMS, Twitter </li></ul>
    16. 16. Нека да обобщим <ul><ul><li>CI позволява бърза обратна връзка при промени </li></ul></ul><ul><ul><li>Кодът е в завършено състояние, можем да направим release по всяко време </li></ul></ul><ul><ul><li>Приложението стига по-бързо до QA </li></ul></ul><ul><ul><li>Дава възможност на екипа да се занимава с по-интересни неща </li></ul></ul><ul><ul><li>Задържа добрите инженери във фирмата </li></ul></ul><ul><ul><li>Release early, release often </li></ul></ul>
    17. 17. Нека да обобщим <ul><li>Прави по-лесно откриването на проблеми, веднага щом се появят </li></ul><ul><li>При много-платформени приложения позволява намирането на бъгове, специфични за отделните платформи </li></ul><ul><li>Намалява несигурността на екипа в продукта и премахва нежеланието за промени </li></ul>
    18. 18. Демо
    19. 19. Какво е TDD <ul><li>Начин на работа </li></ul><ul><li>Кратки итерации за development </li></ul><ul><li>TF D </li></ul><ul><li>Позволява лесна промяна на кода </li></ul><ul><li>Намалява броя на проблемите в приложението </li></ul>
    20. 20. Начин на работа <ul><li>Помислете върху дизайна на кода </li></ul><ul><li>Добавете тест </li></ul><ul><li>Пуснете тестовете и вижте дали новият тест “гърми” </li></ul><ul><li>Напишете кода, така че тестът да мине </li></ul><ul><li>Пуснете тестовете и проверете дали минават </li></ul><ul><li>Рефакторирайте </li></ul><ul><li>Обратно на 1 </li></ul>
    21. 21. Каква е ползата ? <ul><li>Изчистваме изискванията на функционалността </li></ul><ul><li>Изисква да пишем слабо свързани компоненти </li></ul><ul><li>Описваме дизайна на кода чрез теста </li></ul><ul><li>Имаме завършен regression suite </li></ul>
    22. 22. А какви са минусите? <ul><li>Необходима е подкрепа от мениджмънта – иначе изглежда, че пилеем време </li></ul><ul><li>Трябва да поддържаме и вече написаните тестове </li></ul><ul><li>Обикновено един и същи човек разработва и теста и кода (възможни са еднакви грешки) – Pair Programming ? </li></ul><ul><li>Многото минаващи тестове могат да подведат мениджмънта и да намалят останалото тестване </li></ul>
    23. 23. Кога TDD е излишно <ul><li>Няма дисциплина </li></ul><ul><li>Няма се ясна визия какво трябва да прави системата </li></ul><ul><li>Нямате идея как да направите кода слабо свързан </li></ul><ul><li>Мениджмънта не се интересува от качество, а само да пусне продукта </li></ul><ul><li>Кода няма да се поддържа </li></ul><ul><li>При поддръжка на стар код/ стари системи </li></ul>
    24. 24. Ресурси <ul><li>Test Driven-- Practical TDD and Acceptance TDD for Java Developers http://www.manning.com/koskela/ </li></ul><ul><li>Unit testing with mock objects - http://www.ibm.com/developerworks/library/j-mocktest.html </li></ul><ul><li>Hudson Wiki - http://wiki.hudson-ci.org </li></ul><ul><li>Sonar Wiki - http://docs.codehaus.org/display/SONAR/Documentation </li></ul><ul><li>Презентация за TDD на Адриан Митев – http://www.slideshare.net/adrianmitev/testdriven-development-6014243 </li></ul>
    25. 25. Въпроси <ul><li>За въпроси и контакти </li></ul><ul><li>Email: [email_address] </li></ul>

    ×