Komentarze do: Continous integration – i po co to wszystko? http://blog.testowka.pl/2010/01/19/continous-integration-i-po-co-to-wszystko/ Blog o jakości oprogramowania. Thu, 02 Feb 2012 18:56:47 +0000 http://wordpress.org/?v=2.9.2 hourly 1 Autor: Tommy http://blog.testowka.pl/2010/01/19/continous-integration-i-po-co-to-wszystko/comment-page-1/#comment-4170 Tommy Mon, 30 May 2011 10:59:54 +0000 http://blog.testowka.pl/?p=227#comment-4170 Fajnie napisane pomimo lekko nierzeczywistej realizacji - bez uwzględnienia czasu na naprawę błędów i powtórne testy. Ale właśnie możliwość szybkiej weryfikacji poprawek błędów jest wielkim plusem CI. Fajnie napisane pomimo lekko nierzeczywistej realizacji – bez uwzględnienia czasu na naprawę błędów i powtórne testy.
Ale właśnie możliwość szybkiej weryfikacji poprawek błędów jest wielkim plusem CI.

]]> Autor: Wiking http://blog.testowka.pl/2010/01/19/continous-integration-i-po-co-to-wszystko/comment-page-1/#comment-4165 Wiking Mon, 04 Apr 2011 10:30:05 +0000 http://blog.testowka.pl/?p=227#comment-4165 Fajnie napisane - brakuje jednak mi jednozdaniowego podsumowania: "CI lepiej zapobiegac powstawaniu bledow niz je pozniej naprawiac" Dzieki CI unikamy wielu bledow poprzez natychmiastowe informacje Programista1 - twoj kod powoduje konflikt podczas commit, Programista2 - po dodaniu twoich zmian kod sie nie kompiluje itd... Proces CI ma to do siebie ze mozna go zmodyfikowac i stowrzyc taki ktory ma maksymalnie ulatwic prace jak i podniesc jaskosc. np: - commit - build - publikuj artefakty - weryfikacja poprawnosci kodu - deploy - automatyczne testy funkcjonalne - automatyczne testy wydajnosciowe Ostanie 2 punkty realizowane sa juz po wystawieniu wer na server testowy. Testy mozna planowac i np. podzielic funkcjonalne na Sanity check oraz wszystkie, a w przypadku testow wydajnosciowych w zaleznosci od rodzaju testu mozna ustawic kiedy ma byc uruchamiany. Fajnie napisane – brakuje jednak mi jednozdaniowego podsumowania: “CI lepiej zapobiegac powstawaniu bledow niz je pozniej naprawiac” Dzieki CI unikamy wielu bledow poprzez natychmiastowe informacje Programista1 – twoj kod powoduje konflikt podczas commit, Programista2 – po dodaniu twoich zmian kod sie nie kompiluje itd…

Proces CI ma to do siebie ze mozna go zmodyfikowac i stowrzyc taki ktory ma maksymalnie ulatwic prace jak i podniesc jaskosc.

np:
- commit
- build
- publikuj artefakty
- weryfikacja poprawnosci kodu
- deploy
- automatyczne testy funkcjonalne
- automatyczne testy wydajnosciowe

Ostanie 2 punkty realizowane sa juz po wystawieniu wer na server testowy. Testy mozna planowac i np. podzielic funkcjonalne na Sanity check oraz wszystkie, a w przypadku testow wydajnosciowych w zaleznosci od rodzaju testu mozna ustawic kiedy ma byc uruchamiany.

]]>