Отговори на тема  [ 13 мнения ] 
Build Automation, CI/CD Pipeline, DevOps 
Автор Съобщение
Ранг: Минаващ
Ранг: Минаващ

Регистриран на: Съб Мар 18, 2006 11:44 am
Мнения: 92
Мнение Build Automation, CI/CD Pipeline, DevOps
Темата за Test Driven Development ме напомни, че отдавна се каня да попитам ползвате ли някое от горните (Build Automation, CI/CD, DevOps), на какви тулове и организация сте се спрели, в случай, че да, предимства, недостатъци, мотики. Ще се хващам да организирам такова нещо, но за момента съм още на етап проучване, та всякакви коментари ще са от полза. Става дума за ARM Cortex-M4 (STMicro, FreeRTOS, etc.), не за Embedded Linux, Yocto, OpenEmbedded, BitBake и тем подобни.


Пон Юли 18, 2022 6:51 pm
Профил
Ранг: Форумен бог
Ранг: Форумен бог

Регистриран на: Пон Мар 13, 2006 12:59 pm
Мнения: 3855
Местоположение: Габрово
Мнение Re: Build Automation, CI/CD Pipeline, DevOps
За всичките тия дето си ги изредил, няма логика да ползваш различни инструменти. Имам предвид на високо, организационно ниво. Аз винаги препоръчвам teamcity на jetbrains, но много фирми ползват jenkins (същото, ама ... нищо общо).
На това високо ниво ти трябва инструмент, който да може да интегрира различни специализирани по-малки инструментчета - за сорс контрол, за билд, за статик код чек, за тестване, за пакетиране и деплойване.
От моя опит съм установил, че TeamCity е много силен и удобен точно това да прави - лесно и качествено да дефинираш връзките между отделните стъпки е процеса на "производството" на софтуерен продукт (фирмуер, както му викаме за ембедед).
Има един фаворит за билд система - казва се "tup build". Идеологият на make, но далеч по-универсално. Тази система позволява да описваш "файлове" и инструменти във верига от зависимости. Супер е, но за CI/CD има един кусур - базирана е на файл системата, т.е. работи с локални файлове и не знае нищо за разпределени системи/сървъри. ТиймСити идва на помощ - той пък е чуден да се организира същото, като се грижи и за това да следи сървърите и да тригерира работата когато има нужда.
Друга голяма екстра е че позволява да се параметризира целия билд чеин - ако познаваш AUTOSAR, там има едно "управление на вариантите" - т.е. набори от параметри, които дават определени конфигурации на продукта. Имаш примерно контролер за стоп и от БМВ искат да мига 3 пъти през 200мс и после да светне постоянно, а от Опел искат да мигне 2 пъти. Сичко ти е еднакво и реално си имаш на пред-компилатор дефиниция колко пъти и през какво време. Та целия билд не му пука колко ще са мигванията, стига някой да дефинира колко иска сега. Така си правиш един билд чейн и накрая можеш да дефинираш "вариант БМВ" и "вариант ОПЕЛ". След като ги дефинираш... си готов фоервър. Един хинт - това си го представи с връзка към SAP или веб сайта на фирмата, и клиента влиза и сам си дефинира колко мигвания иска. Т.е. "отваря" цялата система да може да свързва и да си говори с други системи.
За ембедед влизат още инструментчета като qemu и renode-подобните. Задължително докер контейнери за всичко.

Оф, темата е огромна - не е за форумно писане.


Пон Юли 18, 2022 9:28 pm
Профил
Ранг: Форумен бог
Ранг: Форумен бог

Регистриран на: Нед Сеп 26, 2004 8:21 pm
Мнения: 27949
Местоположение: София
Мнение Re: Build Automation, CI/CD Pipeline, DevOps
Интересно, въпреки че е много далеч от моята дейност. Само едно нещо малко ме смути, но предполагам по -скоро го даде като пример за гъвкавост ... давали ли сте на клиент възможност до такова ниво да се автоматизира та да му се генерира фърмуера автоматично, и не създава ли това повече проблеми от колкото решава, в смисъл да сетне параметри които не само не му трябват ами са и опасни или нежелани? Т


Пон Юли 18, 2022 10:46 pm
Профил
Ранг: Форумен бог
Ранг: Форумен бог
Аватар

Регистриран на: Нед Окт 31, 2004 8:19 pm
Мнения: 4410
Местоположение: Stara Zagora
Мнение Re: Build Automation, CI/CD Pipeline, DevOps
https://www.kinook.com/VisBuildPro/ аз ползвам това. Аз съм доволен. Като за моите нужди е супер


Вто Юли 19, 2022 7:59 am
Профил
Ранг: Форумен бог
Ранг: Форумен бог

Регистриран на: Вто Окт 11, 2011 10:53 pm
Мнения: 4174
Местоположение: Brussels / Пловдив
Мнение Re: Build Automation, CI/CD Pipeline, DevOps
ToHu написа:
Интересно, въпреки че е много далеч от моята дейност. Само едно нещо малко ме смути, но предполагам по -скоро го даде като пример за гъвкавост ... давали ли сте на клиент възможност до такова ниво да се автоматизира та да му се генерира фърмуера автоматично, и не създава ли това повече проблеми от колкото решава, в смисъл да сетне параметри които не само не му трябват ами са и опасни или нежелани? Т

Досега не съм виждал някой да стартира билд когато на клиента му потрябва нов фирмуер. Винаги нещата са на релийз т.е. замразява се добавянето на нова функционалност и само се изчистват проблеми, после се тества и накрая се изкарва релийз със съответната му там версия и т.н. Технически няма проблем за всеки клиент да се стартира и билдване като му потрябва но тогава всички тези стъпки трябва да са автоматизирани което е доста сложно защото много от валаидациите и тестовете се правят на ръка от програмистите ...

_________________
Мразя да мразя ...


Вто Юли 19, 2022 8:35 am
Профил
Ранг: Форумен бог
Ранг: Форумен бог

Регистриран на: Пон Мар 13, 2006 12:59 pm
Мнения: 3855
Местоположение: Габрово
Мнение Re: Build Automation, CI/CD Pipeline, DevOps
ToHu написа:
Интересно, въпреки че е много далеч от моята дейност. Само едно нещо малко ме смути, но предполагам по -скоро го даде като пример за гъвкавост ... давали ли сте на клиент възможност до такова ниво да се автоматизира та да му се генерира фърмуера автоматично, и не създава ли това повече проблеми от колкото решава, в смисъл да сетне параметри които не само не му трябват ами са и опасни или нежелани? Т


Не в този смисъл - на customer relations и marketing-а им показвах как мога да получават cutsom артефакти, без да се налага да търсят дивелопър да им ги създаде. Ще обясня по-подробно - доставяме на клиенти (различни, А, Б, Ц) пакети, които те да флашнат на нашите устройства в техните машини. Тия пакети имат фирмуер (hex да кажем), но и няколко други файла (артефакта). За клиента това е невидимо, защото сичките файлове са си архив някакъв.
Всеки клиент ползва нашите устройства в различни негови машини - т.е. Клиент А има машина X, машина Y и машина Z. В старите времена, това което правехме е да доставяме голям общовалиден фирмуер, който поддържа всички функции, нужни на всички клиенти за всички приложения - т.е. compile time всичко беше вътре, а опциите се контролират от параметри, които клиените могат да настроят после със конфигурационен софтуер - т.е. да изберат една от три възможни опции, да включат едно, да изключат друго.
В по-големите устройства имаме нещо като виртуална машина и на него клиентите могат да "програмират" поведението на устройството - нещо като да дадеш платка с линукс и API клиентите да си пишат скриптове. В старите времена клиентите вземаха общовалидния, глобален фирмуер, флашваха го, после взимаха конкретната програма ("скриптове"), която е специфична за точното приложение (т.е. казва се "Клиент_А_машина_Z") и я зареждаха, като по същия начин зареждаха и "конфигурация" от параметри, дето настройват глобалния фирмуер да се държи по някакъв конкретен начин.

Конкретната движеща сила да се автоматизират нещата, беше това че (важен) клиент ползваше много бройки от дадено устройство, и гонеше ускоряване на целия процес по "изграждането" на машината. Т.е. искаше да си спести всички ония ръчни стъпки отгоре, които трябваше да повтаря многократно и имаше риск да сбърка. Колегите бяха направили един инструмент (ПЦ софтуер), с който да "автоматизират" тоя процес - т.е. те подготвяха zip архив с отделните части (u-boot, kernel, root-fs, програма, конфигурационни параметри и други неща). Това решаваше част от проблемите, но подготвянето на тия пакети и техните варианти беше ръчно и имаше шанс за много грешки. Отделно, тоя глобален фирмуер съдържаше много плява, която те не ползваха (мъртъв код, дето се вика). Говорим за 80% от фирмуера че беше код, който те няма да използват никога.
Та първата стъпка беше да се огранизира процеса, който подготвя тия архиви (пакети) и това се случва като има нов commit в сорс контрола и излизе нов фирмуер, който минава (не-много-пълно) тестване. Но се случва и ако някой инжинер реши че трябва да пренастрои нещо в конфигурацията, или реши да смени "програмата" (скриптовете), или някой тестер реши да разшири някакъв тест проект. Промяната на какво и да е по билд чейна води до тригер на нов билд.
Тъй като тестването не беше автоматизирано достатъчно, този пакет не се пращаше автоматично на клиента, макар че един ден трябва да стане точно това - тоя пакет да се "деплой-не" на някакво artifact repository като нова версия, и машините, които го ползват могат да си го вземат автоматично (ако клиента е разрешил автоматичния ъпдейт, при рестарт на системата, при периодична поддръжка и т.н.). Реално се пращаше известие на QA че има нов пакет (release кандидат), който трябва да го прекарат през все-още-не-автоматизираните стъпки.

Тъй като билд чейна, който направих, беше вече параметризуем (благодаря, TeamCity), видях че мога да променям билда и някой вариант-специфични опции да ги командвам на ниво билд, т.е. да се уточняват още билд тайм. Това беше възможно, защото по договорка с клиента, имаше вече дефинирани два order code-а да го кажем в системата за поръчки и производство, които бяха един и същ хардуер на 100%, но имаха разлики в софтуерното поведение. Тия разлики реално избираха измежду два взаимноизключващи се варианта на един софтуерен модул, и това беше идеално за избиране по време на билда.
Та там сработи това - реално не се прави напълно случаен нов фирмуер, а се уточняват билд тайм опции - т.е. конфигурира се билда. Благодарение на тия и подобни оптимизации, доставяните пакети спаднаха като размер 10 пъти за някой варианти. Оказа се обаче, че има и друг клиент, който иска да може рънтайм да избира от множество опции (други - не взаимноизключващи се). Та там вече имаше нужда от още работа, но това не се направи и остана за по-нататък.

Това, което е показвано на маркетинга и началството, е тая опция целия развоен процес да се направи като верига, която "може" да се параметризира и да се дефинират варианти. Досега не знам някой друг, освем мен, да е създавал варианти - но най-малкото, един от параметрите, който се сменяше най-често, беше "версията/идентификатора" на фирмуера. Имам предвид че има един текстове, от сорта на "ProductA_3.4", който просто са забити като текстове във фирмуера (преди ползвахме примерно SVN ревизията, но това не е добре). Тия текстове по никакъв начин не влияят на поведението на софтуера, те са нещо като "брандиране" :) Та тяхната смяна преди изискваше да се пусне един двучасов билд на целия линукс и всичко останало, и да се направят няколко ръчни архивирания. Това донякъде е като "tag-ването" в сорс контрола - само че тук се ползват средствата на CI системата, за да има проследимост. По-точно, се ползва една екстра пак на TeamCity - че има вградено "artifact repository" - иначе има и външни такива като JFrog artifactory, но там искат кинти.

Не виждам както стряскащо има в това да се даде на клиент интерфейс/API, през което да може да си настройва билда? Става въпрос за предварително уточнен набор от променливи/опции - поне засега, макар че като се замисли човек, тия опции са "неща дето съм проверил/сигурен съм че ще работят" - т.е. ако има начин други екстри да се валидират че няма да съзадат проблеми, защо да не се отвори интерфейса и те да могат да бъда сменяни?

Реално погледнато, CI принципно не е нищо повече от вариант на билд тул - примерно make, но е разширен с някой екстри:
- файловете не е нужно да ги има налични във локалната файлова система - могат да са на различни места - репозиторита, файлови сървър и други - CI се грижи да опреснява файловете и да ги доставя до местата, където ще се прави билда (като там има екстрите това да изолирани обкръжения, най-често докер контейнери)
- тригерирането не е само ръчно при команда "make all" - тригерира се при промяна в определен файл, което е възможно ако сървърите предоставят механизъм за такова известяване (hook-ове); ако го няма, се пуска периодичен polling и се гледа версията дали се е сменила (вместо датата на файла в мейк)
- съхранява много информация (лог-ове), за да може да се изпълни стар билд точно по същия начин, както и да може да се направи справка даден билд в какъв контекст е извършен - версии на файлове, логове, стойности на променливи на обкръжението, ...
- и нещо много важно - съхранената информация какво и как се е случвало, е добре огранизирана и достъпна през удобен интерфейс
А общите неща са много - build chain-а е същото описание на зависимости и тулове (команди), които казват "как при промяна на main.c да се генерира main.o". И на двете места можеш да опишеш зависимости 1 към много - можеш да кажеш че генерирания хедър "config.h" е от значение за много различни C файлове. Тука да отворя скоба - споменатия "tup build" има много екстри сам да хваща зависимости и така улеснява и опростява правенето на билд описания, но това няма общо с CI.

Реално погледнато, ако приемем че стъпката по взимане на всички нужни файлове в локалната файлова система е свършена, то няма никакъв проблем същите неща да се направят и в мейкфайл или скриптове.


Вто Юли 19, 2022 9:31 am
Профил
Ранг: Форумен бог
Ранг: Форумен бог

Регистриран на: Пон Мар 13, 2006 12:59 pm
Мнения: 3855
Местоположение: Габрово
Мнение Re: Build Automation, CI/CD Pipeline, DevOps
palavrov написа:
много от валаидациите и тестовете се правят на ръка от програмистите ...

Това е за темата за TDD. Идеята на CI е точно това да се избегне, и да, съгласен съм че изглежда като повече работа. Но ако вече имаш тестовете, т.е. не разчиташ някой "да си поиграе с приложението и да види дали няма да се издъни", то няма причина да не могат да се изпълнят автоматично. С ембеддед е по-трудно това, но то всичко ни е по-сложно в ембедеда.
То CI по дефиниция не е възможен без автоматизирани тестове. Цялата идеология е "ако програмиста може да измисли и изпълни теста, какво му пречи да го опише на скриптче или нещо подобно и да го остави да си работи отсега насетне винаги?". Това важи за всяка една стъпка в процеса - "ако тоя може да зип-не един архив ръчно, значи трябва да напишем скриптче да го прави автоматично".
А пак за TDD - там правилото е unit тестовете да са част от билд описанието, т.е. да могат да минат при билд - може би не всеки билд, но поне допълнителен таргет в мейка, който да го прави удобно.
За интеграционните е по-различно - или поне така казват. Аз съм на мнението, че интеграционния е пак unit тест - само че тоя път "unit"-а е цялото приложение/устройство. Т.е. пак трябва да му осигуриш зависимостите и да направиш mock-ове и тем подобни, да му подадеш тестови вектори и да намериш начин да получиш обратно резултата. Ако е примерно GUI, може да се наложи да гледаш фреймбуфера, ако е ембедед устройство с LCD дисплей можеш да хващаш интерфейса към дисплея (като сигнали - с data aquisition карта) и да ги анализираш после.
Всичко е възможно в тоя живот, но някой неща са малко вероятни.


Вто Юли 19, 2022 9:49 am
Профил
Ранг: Форумен бог
Ранг: Форумен бог

Регистриран на: Нед Сеп 26, 2004 8:21 pm
Мнения: 27949
Местоположение: София
Мнение Re: Build Automation, CI/CD Pipeline, DevOps
Мерси много за изчерпателното обяснение, както казах това е далеч от моите занимавки и компетенции въпреки, че боря сходни проблеми но от хардуерно естество, доколкото може да са сходни.


Вто Юли 19, 2022 9:51 am
Профил
Ранг: Форумен бог
Ранг: Форумен бог

Регистриран на: Пон Мар 13, 2006 12:59 pm
Мнения: 3855
Местоположение: Габрово
Мнение Re: Build Automation, CI/CD Pipeline, DevOps
То и аз не съм много на ниво, ама ми е гъдел и от няколко години се мъча - забавно е и ми дава идеи за много други области - вкл. дизайна на софтуера (архитектура). Мисля си че има един общовалиден принцип, който може да се приложи навсякъде, и си го изчиствам на база опита от различни области, и ако щеш, експерименти по темата.
Най-базово, всеки процес може да се разглежда (опише, менажира) като DAG: https://en.wikipedia.org/wiki/Directed_acyclic_graph
С хардуера сигурно има общи неща, но пък аз се поотадалечих в последните години и не следя новините в тия посоки. Сигурно разните тежки вендори на EDA инструменти имат интересни решения. Как иначе се прави чип със 100 милиарда транзистора...
Аз намирам много сходства с управлението и организацията на процесите в производството. Щото то нашето е "производство на софтуер". Има си материали, производствени операции, контрол, зависимости от доставки, инструменти, заготовки, краен продукт и реално тоя 'pipeline' дето е в CI не случайно е кръстен така. Интересно ми е какъв е подхода при SAP и сие, и дали нещо не може да се открадне като идея.


Вто Юли 19, 2022 12:47 pm
Профил
Ранг: Форумен бог
Ранг: Форумен бог

Регистриран на: Нед Сеп 26, 2004 8:21 pm
Мнения: 27949
Местоположение: София
Мнение Re: Build Automation, CI/CD Pipeline, DevOps
Да, тука си съвсем прав, както за DAG, това имаше термин на Български но не мога да се сетя. Аз като говоря хардуер, в основни линии имам в предвид готовото желязо, а то само по себе си е изражение на производствен процес, поне за мен, та да и тука уцели в 10-ката, затова и ми стана интересно писанието ти.
За проектирането на чипове, да и там най-вероятно е така, не съм пипвал подобен софт, но не виждам как иначе ще е, по-скоро прилича повече на писане на софтуер от колкото на дялкане на джелязо, и като процес имам в предвид, поне докато не дойде момента да се дялка силикона.


Вто Юли 19, 2022 3:04 pm
Профил
Ранг: Форумен бог
Ранг: Форумен бог

Регистриран на: Вто Окт 11, 2011 10:53 pm
Мнения: 4174
Местоположение: Brussels / Пловдив
Мнение Re: Build Automation, CI/CD Pipeline, DevOps
Много зависи от проект до проект и от продукт до продукт. Хардуера трудно се тества без да има специален стенд и понякога трябва отделен стенд за всеки тест кейс - а това става бавно и скъпо. И отгоре на това трябва всеки програмист в екипа да има всички тези неща на бюрото си. Т.е. цената за автоматизирано тестване отива в небесата. Сега работя по едни POS терминали които за да минат NFC сертификация от Visa примерно се тестват в лаборатория с робот който размахва една кредитна карта под различен ъгъл и позиция спрямо терминала - айде познай кога ще ми даде някой такъв тест стенд, че и да си го нося в куфара до България ...

_________________
Мразя да мразя ...


Сря Юли 20, 2022 9:46 am
Профил
Ранг: Форумен бог
Ранг: Форумен бог
Аватар

Регистриран на: Съб Сеп 25, 2004 11:32 am
Мнения: 7878
Местоположение: София
Мнение Re: Build Automation, CI/CD Pipeline, DevOps
nixx написа:
Темата за Test Driven Development ме напомни, че отдавна се каня да попитам ползвате ли някое от горните (Build Automation, CI/CD, DevOps), на какви тулове и организация сте се спрели, в случай, че да, предимства, недостатъци, мотики. Ще се хващам да организирам такова нещо, но за момента съм още на етап проучване, та всякакви коментари ще са от полза. Става дума за ARM Cortex-M4 (STMicro, FreeRTOS, etc.), не за Embedded Linux, Yocto, OpenEmbedded, BitBake и тем подобни.


Основата на всяко CI/CD е съвсем конкретните и уникални продукти, екосистема и процес на всяка фирма. Правилния подход е отначало да се работи без това нещо, докато не станат ясни конкретните стъпки на производството: монолитност или модулност, има ли тестове и какви са, има ли диплой и какъв е, формата на крайния продукт (.ехе за счетоводителката или .hex за цеха) и съответните съпътстващи атрибути (документация и прочие) и т.н.


Чет Юли 21, 2022 12:01 am
Профил
Ранг: Форумен бог
Ранг: Форумен бог

Регистриран на: Пон Мар 13, 2006 12:59 pm
Мнения: 3855
Местоположение: Габрово
Мнение Re: Build Automation, CI/CD Pipeline, DevOps
palavrov написа:
И отгоре на това трябва всеки програмист в екипа да има всички тези неща на бюрото си..... айде познай кога ще ми даде някой такъв тест стенд, че и да си го нося в куфара до България ...

Защо? Какъв е проблема да имаш достъп до тоя стенд отдалечено? Както и всички останали колеги? CI е точно за да помогне в тия ситуации, а не да пречи. Ако питаш мен, аз бих предпочел тоя стенд да е някъде надалеч, да не ми се мятка на бюрото (с още два-три от други проекти). Има, разбира се, изключения, ама то затова си има развойни платки - много вероятно е истинския хардуер да се появи месеци след написването на софтуера, или даже да отнеме още няколко дни или седмици да ми бъде доставен след като е готов. Когато е един е по-вероятно да се намерят средства да се направи като хората - ако щеш от качество на компоненти, до по-добри автоматизации за подаване (стимулиране) и събиране на резултатите. Има и междинно решение - като си там си имаш собствен, тежък стенд, а като си дойдеш го ползваш отдалечено.
Конкретно TeamCity има една екстра, дето съм я казвал вече няколко пъти - и тя е да се интегрира в средата ти (Еклипс, визуал студио, Clion и т.н.), или в git workflow-а ти, и да ти дава достъп до CI инфраструктурата (или, в твоя случай, дори само до тестващата част от pipeline-а, или до "билд+тест" стъпките), и ти позволява да "промушваш" нелегален код (дето даже не е качен на сорс контрола - локалните модификации - автоматично в поддържаните среди, малко ръчно но с възможност за скриптиране от конзолата - т.е. да си генерираш пач със промените и да му го пратиш, или дори да му пратиш ELF-а който ти си билднал и той само да го изтества). Той (TeamCity) се грижи да пусне скрит билд и тест на твоя код, без да се вижда във логовете (е, вижда се от теб и евентуално който трябва, но поведението му за такива билдове по принцип е различно от "явните"). Като стартираш тоя билд, можеш да си го наблюдаваш как върви, но можеш и да се върнеш и да продължиш да пишеш - като свърши ще получиш известие със статуса (в еклипса, или на пощата, слак и тем подобни). И ако си мързелив като мен, ще се възползваш от екстрата да включиш един чекбокс докато пращаш кода в началото - да му кажеш "ако билда и теста са ок, качвай на гит с ей тоя коментар". В тоя случай искаш известие само ако гръмне билда или теста, но не и ако е успешен - защото твоята работа по тая задача е приключила - кода е качен с информация за успешен билд и тест.
Това, което дава горница тая постановка, е че този "скрит" (викат му частен - private build) минава през същите механизми, както и "нормалните" билдове - т.е. целия механизъм за контрол на ресурсите от пайплайна си сработва по същия начин - няма как да стане "ами счупи ми се теста, щото някой пускал и той в този момент".
А накрая това дава екстрата, че с един брой тестов стенд могат да работят N-броя програмиста, а и целия QA екип - така се спестяват пари. Ако това се окаже тясното място - няма проблем, пуска се паралелно още един "node" - все едно да можеш да ползваш още едно ядро. И ако не си подходил правилно с дизайна на софтуера (т.е. на процеса в нашия случай), и 10 ядра (node-а) да ти дадат може пак да работи със скоростта на едно. И понеже принципите и "рестрикциите" на тия CI системи, с там разните инфраструктура-като-услуга (докер и техните мениджмънт обвивки) те водят как да изградиш процеса по правилния начин. Това може да стане във всеки тул за CI, но при TeamCity е направено да ти е удоволствие - т.е. не те товари, подсказва ти какво да направиш, вади предупреждения ако забележи кофти изпълнения, и т.н.

Цитат:
Правилния подход е отначало да се работи без това нещо

Ами то това е малко като да кажеш "в началото да го направим без да го мислим (дизайн), пък после ще видим". Да знаеш конкретните стъпки го разбирам да си правил и други софтуерни продукти - да знаеш че има събиране на изисквания, дизайн, програмиране, разработка на тестове и т.н. Т.е. да имаш знания и подход как да захванеш тоя проект от самото начало. Моето мнение е че се почва от това, което трябва да доставиш - като за него съдиш по изискванията. В твоя пример, екзето за счетито идва от мейла и, в който обяснава че от НАП и пращат едни таблици, и ги искат попълнени, пък тя досега има същото в едни друг таблици, и не иска да ги копира/форматира на ръка. Та тук трябва да се уточни тя shell скрипт ли очаква, и като се ококори на въпроса, значи GUI ли очаква, или плъгин за ексела, или казва че не иска и да знае - нали качва оригиналните на еди коя си папка на сървъра, не иска да пипа, значи някой трябва да измисли как да открива промени в тая папка и да изпълнява код. Оттам вече излиза алгоритъма - като се вземе описанието на единия и другия формат, се вижда каква е функцията, ама изскача и това че новия формат искал данъчния номер примерно, пък той го имало еди къде си, значи трябва да се добави откъде да се взема. Така се изчиства какво се иска - какво трябва да "достави" програмиста, за да задоволи :oops: счетоводителката. На какъв език? Ми ако счетито няма претенции, ако сървъра няма претенции, то на какъвто си прецени той, т.е. избираме най-евтиния сътрудник, който може да го свърши примерно. В тоя ред на мисли възниква нуждата от описание на стария и новия формат, за да може да се измисли алгоритъма за трансформация. Може да се окаже че описание на старото няма, т.е. възниква задача някой да анализира документа и да го документира (да му направи модел). И така назад по веригата докато се стигне до неща, които вече ги има. Там приключва задата - в смисъл на дизайна. Много е вероятно имплементирането (на кода и на тестовете) да започне в обратния ред - първо да се направи анализа на старите таблици, после да премине нататък докато се стигне до готово ексзе и тестовете, който "задоволяват" счетоводителката.

Едит: тъй де, исках да кажа че когато си наясно с идеята на CI, за следващите проекти можеш да почнеш направо с автоматизирания вариант. Но има и резон всяка от стъпките да може да се изпълнява и ръчно, но си има начини двете неща да се съвместят.


Чет Юли 21, 2022 12:39 pm
Профил
Покажи мненията от миналия:  Сортирай по  
Отговори на тема   [ 13 мнения ] 

Кой е на линия

Потребители разглеждащи този форум: Google [Bot] и 7 госта


Вие не можете да пускате нови теми
Вие не можете да отговаряте на теми
Вие не можете да променяте собственото си мнение
Вие не можете да изтривате собствените си мнения
Вие не можете да прикачвате файл

Търсене:
Иди на:  
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group.
Designed by ST Software for PTF.
Хостинг и Домейни