А якщо ми деплоїмо з гілки «feature-shototam» на «dev2» то що ми зрозуміємо з назви гілки?
Мій підхід суто для того, щоб по назві джоби відразу розуміти куди пішов деплой. Щоб не було необхідності клікати на джобу, і перевіряти назву енву в логах. Він лише для візуалу, тільки і всього.
Якщо такої необхідності немає — ваш варіант буде навіть кращим, адже прибирає зайву складність
Вибачте за стиль, я просто намагався писати «цікаво» (щоб зацепити). В мене не було мети «знецінення» іншого бачення, яке не співпадає з моїм! Я лише хотів сказати: «я роблю ось так, для досягнення таких цілей...»
Просто мінусом текстового контенту є те, що читач не завжди може оцінити «емоційне» забарвлення цього тексту. Тому багато жартівливих моментів (як я собі напочатку задумав) можна трактувати як агресивне подання матеріалу. Я обов’язково врахую це в наступний раз.
Не піценосів, а фізруків, попрошу ))
1. В вашому прикладі з locals, ви задаєте «дефолтное значение, которое определяется на основании других переменных», або даєте можливість передати кастомне значення.... Тобто ви пеередаєте кастомне значення в «child» модуль, яке ВЖЕ згенерували в «root» модулі? По факту робите так, як я раджу в статті (але не завжди)?
Тоді чому б не викинути ці locals з «child» взагалі, і не перенести їх в «root» модулі, якщо ви все рівно в «специфічних» випадках виносите їх генерування в «root» ?
Я все ж впевнений, що це спростить розуміння логіки коду.
2. Згоден, це сугубо суб’єктивно. Для мене мій варіант здається «зрозумілішим» (наприклад, для людини, яка онбордиться на проект)
3. Ви знову ж таки передаєте ВЖЕ готове значення для «some_var_changed_by_1%_of_child_modules_bool», яке було згенероване в «root» модулі (або ж ставите дефолтне значення, якщо такого немає). Ви не генеруєте значення для пропертів ресурсів в locals «child» модулю, ви лише вказуєте дефолтне значення (що ніяк не суперечить моєму підходу). Але це тяжче читати....
Ну правда, це ви опишете близько 15 lookup-пів ? І як це виглядатиме?
Це звісно суб’єктивно, знову ж таки....
P.S: знов повторюсь, що я не претендую на звяння мессії Тераформу. Я лише описую як роблю я, і для чого я так роблю.
Зовсім забув, ще є така штука як «(optional)» в описаннях variables — це щодо того, як можна одночасно «приймати» одним модулем різні об’єкти з різною кількістю пропертів в них.
1. В «ternary operator» є лише «true» або «false», так? Тобто лише два варіанти ? А якщо треба більше?
2. Що на рахунок «readability» такого підходу? Це полегшує читання коду?
3. Що робити якщо ти в «child» модулі маєш прийняти мапу об’єктів, де у кожного об’єкту по
Так, ви праві — версіонування модулів вирішує цю проблему.
Але мій приклад більше про збільшення «flexibility» модулю, щоб він міг приймати і створювати більшу «різноманітність» ресурсів.
P.S: і я ж не кажу, що немає інших альтернатив. Я кажу: «я роблю ось так для досягнення того-то».
1. «прошу уточнити де в офіційній документації згадано що використання count deprecated або це bad practice?» — якщо ви читали мою статтю трохи далі, то я якраз цитую офіційну документацію, де про це згадано. До речі, в посиланні, що ви скинули, теж є про це в останньому абзаці ))
2. З приводу «не зʼясувавши причин чому було щось зроблено так або інакше» — наведіть хоч один приклад/аргумент для використання «count» замість «for_each». Іншими словами: є хоч один кейс, коли ти не зможеш реалізувати щось з «for_each», але зможеш реалізувати з «count»? Які його «переваги» в порівнянні з «for_each» ?
3. Інкапсуляція є механізмом об’єднання данних, методів та атрибутів в об’єкти, з подальшою можливістю(не завжди) скриття цих методів чи об’єктів від зовнішнього світу. І основною причиною для інкапсуляції є: «Essentially, encapsulation prevents external code from being concerned with the internal workings of an object». Тобто, щоб на данні об’єкта не можна було ніяк впливати окрім як із середини самого об’єкту.
По-перше, Тераформ не є ООП мовою програмування, в нього немає классів, методів і т.д.... Якщо ви хочете заперечити, що для інкапсуляції не є обов’язковим ООП — так, це правда, але Терраформ НЕ є не тільки ООП мовою програмування, але й взагалі НЕ є мовою програмування. Тож, цікаво, яке значення інкапсуляції ви вкладаєте в «інкапсуляцію в Тераформ»? Є якесь визначення з офіційних джерел про «інкапсуляцію в Тераформ» ?
По-друге, навіть якщо ми припустимо, що існує якась «інкапсуляція в Тераформ», і вона полягає з ваших слів в «загорнути в середину модуля трохи логіки щоб розрулити вхідні дані різного типу», то яким чином мій підхід заважає вам приймати модулем об’єкти/мапи об’єктів, або значення «locals» різних типів і «розрулювати» їх як ви вважаєте за потрібне?
Моя концепція, насамперед, полягає у формуванні неймінгу чи значень пропертів в «root» модулях, і передачі цих фактичних значень в «child» (це як передавати аргументи в функцію чи в створення об’єкту класу, якщо ви любите аналогії з програмуванням). А що ви вже далі будете з тими значеннями робити — ваша справа. Ви можете одночасно приймати об’єкти з 10 параметрами всередині, і об’єкти з 5 параметрами, але при цьому і ті, і ті будуть «прийняті» вашим «child» модулем, якщо ви опишете, що вони їх можуть приймати (default «" значення ще ніхто не відміняв). Чули щось про «duck typing» та «interfaces» в програмуванні ? Я намагаюсь досягнути саме такого ефекту!
Це робить ваші модулі більш «flexible» в плані різноманітності ресурсів, які вони зможуть створювати.
Так, я якраз про проблеми його використання і говорив!)
Наявність класів не є обов’язковою вимогою для того щоб використовувати ООП.
В GO більше ООП чим в більшості мов програмування з класами
А чому «опустили»? По-перше, «війти в айті» девопсам точно легше через меншу конкуренцію (і плювати на поріг входу). Я думаю, автор коменту саме це мав на увазі. А по-друге..., чи багато девопсів можуть дійсно писати код з ООП, а не лише скріптіки на Python? Не думаю, що Yaml-девелоперство і Terraform-задротство це саме те, як Google уявляє і описує людину, що займається DevOps практиками, в своїй книзі «Site Reliability Engineering».
Девопс описаний в книжках, і девопс, що закриває потреби бізнесу в реальному світі — то різні люди!)
Дякую)
А через 2 роки.... я вже може буду магістром з профільною освітою.... ))
Курси про те, як тикатись немов сліпе кошеня, і пробувати поки не вийде?
Не думаю, що такі курси комусь зайдуть. То радше філософія самурая аніж конкретний план для дій)
Та не хочу я нікуди заходити, дивитись в енвайронментс, розбиратись в нотифікаціях (це ж як треба заморочитись щоб через нотифікації розібратись яка пайплайна куди деплоїлась тиждень назад). Я хочу відкрити ран і відразу бачити з якої гілки і куди пішов деплой. Що, як в мене100-200 деплоїв за день? Я не хочу в цьому всьому копатись!
Навіщо нам переробляти пайпу задля деплою з нових гілок (hot-fix, наприклад)? А якщо у вас один СПІЛЬНИЙ «test» енв, куди девелопери деплоять і тестують свої фічі (з власних feature гілок звісно ж)? Вказати гілку і енв — єдине, що треба робити з точки зору best-practices. А все інше, всі конфіги, всі депенденсі.... хай пайплайна підхоплює сама, і робить своє діло. Єдине, що треба, це встановити необхідні рестрікшени для деплою на прод та інших важливих речей.
А з приводу «можна це зробити менш складно» — що може бути простіше, ніж додати «extend_vars $VAR_NAME» в назву job ?