• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Continuous integration (d.atanasov)
 

Continuous integration (d.atanasov)

on

  • 667 views

 

Statistics

Views

Total Views
667
Views on SlideShare
667
Embed Views
0

Actions

Likes
0
Downloads
2
Comments
0

0 Embeds 0

No embeds

Accessibility

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • Изброи tools за всеки тип тестове – Junit, TestNG, Selenium, WebLoad, Apache Jmeter, OWASP Web Scarab

Continuous integration (d.atanasov) Continuous integration (d.atanasov) Presentation Transcript

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