януари 12

Development 2.0

Ще викам „неволята“, така че помагайте – как да убедя някого, че не е „полезно“ да се deploy-ва и update-ва live машина от /trunk-а ? „Полезно“ е изключително мека дума за това което имам предвид, по-скоро правилния израз е „лекомислено и непрофесионално“. Как може на машина, която се ползва от истински потребители, да сложиш версията от /trunk-а, върху която работят всички разработчици ? Необходимо ли е да се обяснява, че тази версия е „нестабилна“, защото се работи ежедневно върху нея ? За мен е очевидно до толкова, че чак не виждам как някой може да не го разбере и сам. Защо не се tag-не или branch-не една (относително) по-стабилна версия, по която не се човърка всеки ден, и тя да се използва за live машината ? Така е сигурно, че тя няма да стане жертва на някоя изцепка, която може да се случи при ежедневното пращане на код. За мене всичко е кристално ясно, и не проумявам защо други не го проумяват. Това което става сега е егати извратения подход – стига се до там, че разработчиците не commit-ват по повече от седмица, от страх да не прецакат /trunk-а от който са deploy-нати live машините, и така да изцапат пейзажа. Извратена работа, нали ?

За финал, все пак е по-добре да ползваш някаква система за контрол на версиите, дори и по извратен начин, отколкото да не ползваш въобше ;) Все пак 21 век сме, да пишеш софтуеър без система за контрол на кода изглежда като отживелица (от комунизма).

1 коментар

  1. Често срещано явление.

    Обикновенно работата на QA е да тестват последните версии. И да обявяват че е достатъчно стабилна.

    Конкретно аз правя така – когато имам релийз дата седмица предварително замразявам нещата за правене които няма да станат в рамките на датата или ще станат ама бъгави и Ñ‚.н. след което се пуска един дълъг тест и се пипат само малките детайли без много-много нововъведения. Тогава проектите се разделят – стабилна и нестабилна. През седмицата се продължава работата по нестабилната версия и се пипа малко по-малко стабилната (с тенденция все по-малко да се пипа). Така на релийз датата (обикновенно гледам на седмица да е) има една стабилна версия (може с по-малко възможности но СТАБИЛНА) и нестабилна (с повече възможности но НЕСТАБИЛНА). Само има малко ядове по обединяването на промените между версиите, но се свиква (освен ако не са някакви гигантски, но за това си има фаза на проектиране където се преценяват внимателно нещата).

    Comment by Peter — януари 13 @ 14:00

RSS feed for comments on this post.

Sorry, the comment form is closed at this time.