Хороші, прості причини, що мають кілька середовищ

Протягом своєї кар’єри я працював у компаніях, які мали колекцію різних середовищ для різних цілей. У нас завжди було більш-менш наше робоче середовище, тестове середовище, якість забезпечення якості, постановочне та виробниче середовище. Це стосувалося як серверів / програм, так і будь-яких джерел даних, які ми використовували.

Коли я почав працювати в своїй теперішній компанії, я виявив, що 90% додатків були або розроблені на робочому столі проти джерел виробничих даних, або розроблені безпосередньо на виробничому сервері залежно від платформи. Це було не особливо дивно, тому що мене частково прийняли на роботу, щоб внести зміни, щоб покращити функціонування команди розвитку, що було зрозуміло з мого процесу співбесіди. Ми потихеньку почали перетворювати філософію і досить скоро більшість додатків можна було запустити або на робочому столі, і в тестовому, або у виробничому середовищі. Не надто довго після цього відбувалися і постановки.

Зараз більшість наших розробників бачать перевагу цієї методології та пильно захищають її. Однак у нас є ряд застарілих додатків, які ніколи не переміщувалися. Також у нас є низка застарілих програмістів, які вважають це марною тратою часу. На жаль, ми отримали сервісне обслуговування, але ніколи не повний внесок від керівництва. Ми отримали те, що, на нашу думку, було зобов’язанням значно інвестувати в це близько року тому, але нічого не здійснилося, незважаючи на значне планування, яке ми вкладали в це. Зараз ми виявляємо, що нам потрібно все більше середовищ. Для налаштування нам потрібна допомога команд управління сервером / мережею, і нам потрібна участь зацікавлених сторін бізнесу для підтримки циклу випуску. Зараз ми перебуваємо там, де проект може функціонувати, що розумні розробники вважають "нормально"

Я хотів би викласти повний аргумент, але менеджмент насправді не має часу та інтересу вислуховувати мене, поки не з’явиться критична проблема. Я не можу сформулювати переваги просто так, як мені це завжди здавалося другою природою. Мені було цікаво, чи існують якісь хороші, прості, неспростовні причини розмежування середовищ, через які менеджерам не вистачить досвіду розробки для підтримки цієї ідеї? . Чи є хороші ресурси / література з даної теми?

Відповідь: Гроші

Мені все одно, що насправді причина. Гроші ОБОВ'ЯЗКОВО лежать в основі всіх ваших міркувань, особливо коли стосується управління.

Якби ми обидві години сиділи в кімнаті, ми могли б придумати десятки причин, чому краще мати кілька середовищ.

Ось проблема: Якщо причини не ґрунтуються на грошах, то жодна з них не має значення .

Програмістів не приймають на роботу, щоб бути розумними. Їх не наймають для творчості. Їх наймають, щоб збільшити прибуток - заробляючи гроші або заощаджуючи гроші. Якщо ви не робите жодного з цих, краще зібрати своє резюме.

Дивлячись на це з цієї точки зору, відповідь проста:

Наявність лише одного середовища збільшує час простою і призводить до втрати доходу. Кілька середовищ дозволяють нам захищати свої прибутки, надаючи нашим користувачам передовий настільки ж надійний і надійний, як і наша компанія.

Повторюйте це щодня.

Нижче наведено кілька чудових коментарів, які додають реальної цінності цій відповіді, тому я згадаю їх:

• У Карла Білефельдта був чудовий момент, коли він зазначив, що аналіз витрат / вигод є важливим фактором. Економіст міг би позначати це як альтернативну вартість пошуку декількох середовищ. Хоча це може бути дивно чути, є сценарії , де кілька середовищ не можуть бути відповіддю! Якщо веб-сайт вашої компанії є дуже незначним доповненням, то несподіваний час простою може бути фактично більш економічним способом ведення бізнесу. Це не схоже на положення, в якому ви знаходитесь, але це варто згадати.

• У BlairHippo було добре, що ви повинні почувати себе вільними, щоб це здалося катастрофою (а якщо ви втратите свої дані, це так!). Відповідальність - чудовий інструмент для переконання керівників, але все ж з тієї ж причини - судові позови дорогі. Уникнення їх економить гроші.

Як додаток я вважаю цю статтю досить хорошою. Це не відповідає безпосередньо на ваше запитання, але дає змогу розпізнати, як програмісти дивляться на управління, що, в свою чергу, призводить до цієї відповіді. Добре читати.

Єдиний пункт відмови

Не маючи середовища для розробки та інсценування, у вас є єдина точка відмови для цих застарілих додатків. Керівництво почує вас, якщо ви опишете застарілі програми в цих термінах.

Потрібно вміти розміщувати своє повідомлення у звукових байтах, що має для них сенс. Вийміть з програми обговорення " Програмістський виступ " і замініть його на " Говорить менеджером ". Також зробіть вигляд, що у вас 30-секундний проїзд на ліфті, щоб отримати точку в дорозі.

У мене була ситуація, коли моїм начальником був піхотний піхотник. Я постійно казав йому, що мені потрібні програмні засоби та комп'ютерне навчання для моїх морських піхотинців, щоб бути більш продуктивними. Він цього не зрозумів. Я нарешті зайшов у його кабінет одного дня і сказав йому, що справи розпалися.

Я щось сказав про це ... "Якщо я бився у війні, я використовував би палиці, скелі та гілки дерев. Мені потрібні гранати, базуки та кулемети". Він отримав повідомлення.

Це насправді критично?

Я можу зрозуміти бажання використовувати окремі середовища. Неочевидне питання:

Чи насправді критично мігрувати застарілу систему?

Я думаю, що більшість технічно налаштованих людей схильні зосереджуватись на академічному питанні, який спосіб краще, а що є добре в академічних школах. У бізнесі, хоча найкраще не завжди виграє. Я не кажу, що це негативно, або розпочати полум’яну війну. Я констатую очевидне, або те, що повинно бути очевидним для тих із нас, хто займався програмним бізнесом кілька років.

Усі бізнес-рішення зазвичай приймаються на основі сприйнятої вартості / вигоди. Тож питання, яке, мабуть, задає бізнес:

Чи варто вартість додаткової інвестиції в систему та розвиток в застарілому додатку вигідна порівняно з тим, що ці ж інвестиції вкладаються в інший проект / продукт?

Я регулярно і досі регулярно аналізую вигоди за витратами, щоб визначати не лише міграцію / перезапис програмного забезпечення, але й щоденні рішення, як правило, залучаються. Я перейшов до переписування / міграції старого програмного забезпечення, оскільки воно мало обмежений термін експлуатації та тому цінність.

Окремі середовища

У бізнес - причини для поділу середовищ.

• Менший ризик у випусках та виправленнях помилок. Доведіть це цифрами. Скільки разів продукт вийшов з ладу і коштував дохід клієнта через поганий випуск / помилку.
• Менше ризику в розвитку. Випадкове видування продукту db відрізняється від випадкового видування продуктового db
• Здатність чітко розділяти ролі та доступ, тобто. краща безпека. обмеження кількості пальців у виробничому пирозі - це гарна річ
• Можливість розділяти середовище, а також практики та процедури, що узгоджуються з цим стилем розробки, дозволяють надалі розвиватися у хмарних системах.
• Розмежування середовища повинно змусити ефективність у копіюванні середовищ, що може бути корисним як для запланованого, так і для динамічного масштабування.

Здається, у вас усі «правильні» аргументи вже на місці. Натомість ви переживаєте "червону оселедець", якщо хочете. Або "переслідуючи моркву"

менеджмент справді не має часу та інтересу вислуховувати мене, поки не з’явиться критична проблема

Це я вважаю справжньою проблемою. На моєму досвіді, якщо компанія має такі низькі методи розвитку, як ви описуєте. Це не просто питання "ми не знали нічого кращого". Скоріше, це складання технічної заборгованості, спричиненої вищою командою управління, яка не знає (байдуже?) Про проблеми, які вона представляє.

У таких випадках хороша розмова не збирається раптово розгойдувати речі у вашому напрямку. Можливо, сильна травма (відмова продукту помітна клієнтові і безпосередньо пов'язана з поганою практикою), але я впевнений, що розумні фахівці, перш ніж ви спробували розмову.

Моя пропозиція - або висмоктати його і прийняти речі такими, якими вони є, або шукати нову посаду.

Скільки груп людей планують працювати над додатком одночасно? На жаль, я бачив одне середовище для кожної групи людей. Це розробники (вони отримують середовище DEV та середовище інтеграції DEV - дехто вважає, що це не на 100% необхідне, я б сказав, що це залежить від проекту), два тестових середовища (одна група тестувальників робить дуже детальне тестування, інша для тестери якості QA високого рівня - зазвичай це фактичні бізнес-користувачі, а не навчені тестери). Зазвичай існує також ізольоване середовище для тестування продуктивності (так що ви можете протестувати величезні обсяги даних, імітувати величезні обсяги користувачів тощо ... g).

Чому всі ці середовища? Тож різні групи можуть перевірити різні особливості, не наступаючи на пальці ніг. Якщо розробники та тестери працюють в одному середовищі, це кошмар: тестер може відкрити дефект функції, яка активно змінюється розробником щохвилини. Якщо є два рівні тестування, вони можуть зосередитись на різній активності і не турбуватися про те, щоб зіпсувати дані один одного. Наявність ізольованого середовища продуктивності дозволяє запускати тести, які можуть повісити машину, але якщо вона ізольована, ніяких інших тестерів це не вплине.

Коли занадто багато людей намагаються робити занадто багато різних речей в одному середовищі, ви закінчуєте багато витраченого часу, оскільки одна група чекає закінчення тесту іншої групи, щоб вони могли запустити своє. І цей витрачений час, і витрачений час може призвести до марних грошей, які, як зазначає Stargazer712, можуть зробити найсильніший ефект.

Ще одна причина (не настільки поширена) - це дані: якщо у вашій програмі є конфіденційні особисті дані або дані кредитної картки, ви зазвичай не можете вносити це в тестові середовища, і зазвичай існує маскування вимог до всього, окрім середовищ якості та виробництва.

Ви, здається, вклали чимало зусиль для культурних змін на своєму робочому місці. Це велике досягнення, оскільки зміни важкі в найкращі часи, але культурні зміни стосуються не просто зміни розуму людей, а змінити звички, порушити забобони і, зрештою, відкрити потенційно закриті думки для більших можливостей. Тож питання, яке слід задати собі в цей момент, - «Що я пропустив?». Проста відповідь полягає в тому, що ви, можливо, не повністю займалися управлінням.

Придбати менеджмент у мене дуже просто, але ще складніше стає прийняття. Незалежно від аргументів щодо грошей тощо, реальність полягає в тому, що вам потрібно мати можливість впливати на погляд керівництва на пріоритетність. Ваш менеджер матиме бюджет, і він захоче показати, що бюджет застосовувався грамотно і відповідно до цінностей та пріоритетів компанії. Деякі з цих пріоритетів будуть фіскальними, але інші стосуватимуться задоволення інших потреб. У деяких випадках це може означати змащення долонь інших менеджерів, щоб отримати таку рекламу, яку завжди хотів ваш начальник. Однак у більшості випадків, ймовірно, мова йде про пошук способів отримати більше бізнесу або покращити відносини з партнерами та клієнтами. Якщо ви не зможете скласти свою справу в цих умовах, ви зможете зайти так далеко, перш ніж опинитесь у глухому куточку.

Моя пропозиція - спробувати скласти справу щодо продуктивності та того, як це впливає на бюджет, як це пропонували інші, але також зробити так, що стосується пріоритетів вашої компанії та як ваша продуктивність може безпосередньо впливати на відносини компанії з іншими компаніями.

Ось один: заповітність.

Наявність тестового середовища дає вам свободу виконувати тести на базі даних, які було б недоцільно виконувати у виробничих умовах.

Ви хочете змінити, як ваша організація розробляє своє програмне забезпечення? Забудьте турбуватися про "причини" для того, щоб "робити речі інакше". Люди не змінюють поведінку через раціональні аргументи. Вони змінюються через психологічний вплив на свої звички.

Отже, куди я йду з цим?

Хоча час від часу можна успішно змінювати поведінку організації через аргументацію, існують інші тактики, які краще працюють. До них належать:

• Підтримка низкопробних грошей: знайдіть ОДИН інший "застарілий" розробник, який готовий дати вам можливість зняти. Партнерство з ним і змінити, як все працює. Не повідомляйте про зміну. Просто внесіть зміни. Якщо хтось коли-небудь запитає вас про це, просто скажіть "О так, це ми робимо це зараз".

• Беріть на себе відповідальність. Добровольцем працювати з розгортаннями для спадкоємців. Дійте так, як любите. Вони можуть із задоволенням відмовитися від відповідальності. Потім запустіть її так, як вам хочеться.

• Звинувачуйте правильних людей у ​​своїх помилках. Наступного разу, коли застарілий помилка програми буде впроваджена у виробництво через механізм розгортання кам'яного віку, вкажіть це. Робіть це тонко ... Не в електронній пошті. Наступного разу, коли ви зустрінетесь з менеджером, просто випадково згадайте приклад причини, що розгортання було проблематичним. "Ага, пригадайте, як ми каралися минулої п’ятниці через помилку Foo, яку Боб перевірив на виробництво? Так, це було багато витрачених сил!"

• Зробіть це легше зробити це кращим чином. Подивіться, наприклад, на iphone. На ньому є ОДНА кнопка. (Ну, два). ДУЖЕ легко включити. Зробити божевільну безглузду обстановку для розгортання до кількох середовищ просто. Зробити це так просто, що всі менеджери можуть це зробити!

Його питання більше, коли ви починаєте мати справу з взаємопов'язаними або застарілими системами, системами, від яких бізнес залежить, щоб бути працюючим і точним. Це важливо, тому що між етапами має бути відокремлене, це є причиною, чому ви не робите DEV на PROD, оскільки він може потенційно завдати шкоди на мільйони доларів у втрачений час .

Ми завжди робимо DEV -> QA -> PROD (іноді ці кроки розбиваються на більш дрібні шматки) з однаковим обладнанням за ними. Поточні дані про виробництво завжди просуваються від PROD до QA до DEV.

DEV: призначений для роботи з пісочницею розробки, де випробувані речі, повторення та побиття будь-яких даних у цьому середовищі ніколи не слід довіряти, і розробники регулярно перебирають їх у продаж, просто знаходячи шляхи вирішення проблеми.

QA: Після того, як ваші розробники будуть задоволені тестуванням підрозділів, настав час для тестової групи переконатися. Вони запускають тестові кейси, тестування продуктивності та знаходять помилки. Ці помилки / принади повертаються до DEV, і цикл триває, поки всі не будуть задоволені.

ПРОД: Після того, як ви перейдете до цього етапу, ви повинні бути впевнені, що код працює в поєднанні з поточними даними, і ваші користувачі групи QA / бізнесу задоволені реалізацією. Якщо ви все зробили правильно, ви просто зможете оновити код і зробити це з ним.

Таким же чином ви ніколи не випускатимете неперевірений продукт клієнтам, ви ніколи не повинні випускати неперевірений код у виробниче середовище.

Якщо компанія не бажає вкладати час, щоб зробити це належним чином, вона окупить витрати на аварійне обслуговування та помилки в 10 разів.

Як невеликий приклад: у нас була одна компанія, яка вирішила внести зміни до звіту про виробництво самостійно. Ніхто не знав, що це змінилося, поки ми не прийшли вирішити різні проблеми рік-два вниз.

Коли ми вказали на неправильність у звіті, обличчя фінансового директора стало білим, виявилося, що вони втрачали ~ 250 000 доларів на чверть через те, що хтось швидко змінився.

Відбувається частіше, ніж ти думаєш, якщо ти не можеш дозволити собі це зробити належним чином, то не роби цього.

Менеджмент має велику роль за успіхом програмних компаній та програмних продуктів, необхідних для створення цих середовищ. Давайте візьмемо приклад свого проекту. Якщо ваше програмне забезпечення розроблене у великих масштабах, тоді, якщо ви не керуєте своїми проектами, контролем процесів, тестовими збірками тощо, це шанси на збій. щоб управління проектами існувало.

Я дещо згоден з @ Stargazer712, що ваше твердження вказує на Гроші має значення, але перевірте наступне твердження, яке я отримав із книги Марка Гамільтона про розробку програмного забезпечення: Побудова надійних систем (Prentice Hall PTR, 1999, ISBN 0-13-081246- 3). Оглянувши всі ці фактори; моя думка щодо вашого запитання полягає в тому, що єдине середовище не дає вам заощаджень, це дозволить завершити проект / програмне забезпечення довгостроковим процесом. Розподілене середовище заощадить час та дохід, як я дізнався та бачив на своєму досвіді, що сталося з компаніями, що запускають програмне забезпечення, з яких я запустив свого оператора.

Існує багато статей, які демонструють, що важливо для успіху. Перевірте цю організацію для успішної розробки програмного забезпечення

Кожна особа в організації має певні навички, і ці навички, як правило, оцінюються на основі формальних чи неофіційних показників ефективності, що призводять до винагороди (компенсації) як стимулів для майбутньої діяльності. Люди в організації формують її культуру - ті моделі поведінки та цінності, які загалом визнаються прийнятими.

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

Багато запуску програмного забезпечення починають життя, коли в гаражі працює не більше пари розробників. На даний момент в історії компанії не потрібно багато організаційної структури, але організаційна структура все ще існує. Наприклад, у 1977 році, коли Білл Гейтс та Пол Аллен створили своє партнерство і офіційно назвали його Microsoft, компанія мала мінімальну організаційну структуру. У першому офісі Microsoft в Альбукерке, Нью-Мексико працювало менше десятка співробітників, і всі знали, хто відповідає за це. Ніяких складних організаційних схем не потрібно було, щоб визначити структуру звітності кожного. У той же час усі працівники знали свою роль у компанії та те, що вони намагаються досягти. Це було тому, що будь-яка організаційна структура, яка була необхідна, могла неофіційно повідомлятися між кожним із працівників.

Забудьте час, гроші, доказовість, якість ... як щодо репутації .

хороші, прості, неспростовні причини роз'єднання середовищ, через які менеджерам не вистачить досвіду розробки для підтримки цієї ідеї.

Нещодавно Uber поставив код до github, який містив паролі для їхнього прямого середовища , що дозволило "хакерам" завантажити всі дані про своїх клієнтів. Uber стверджує, що це було порушенням, а всі інші кажуть: "не ставте ключі від ваших замків у загальнодоступному огляді. Якби їх розробники працювали повністю на середовищі розробників, вони могли б випустити ключі від свого середовища розробників на github, але це повністю Про те, що виробництво було випущено, показує, наскільки погана ця ідея про створення розробників на виробничому середовищі.

Просто нагадайте своєму менеджеру, що трапляються помилки, тому спосіб уникнути його переслідування перед генеральним директором, який збирається отримати гриль перед журналістами та висміяти технічну громадськість - це зробити прості, очевидні кроки, щоб запобігти катастрофічним помилкам ті.

Здається, що у вас є багато різних середовищ, і люди коштують багато часу, щоб створити "середовище".

У вас має бути найменша кількість різних "середовищ", з якими ви можете піти, але вміти клонувати безліч примірників з тих самих причин, скільки бажаєте ви та компанія (використовуючи "оточення для розуміння конфігурації системи)!

Оптимально єдиними відмінностями повинні бути:

1. Розмір (мінімальний, рекомендований, найбільший підтримуваний / протестований);
2. Постановка та виробництво не мають інструментів розробки
3. Виробництво захищено від випадкового перезапису даних
4. Ви можете дуже легко завантажувати дані демо, тестувати або [аномізувати] клієнтів на сервери розробки та інсталяції

З того питання про те, скільки і яке тестування слід зробити, - це оцінка ризику / вартості бізнесу, яка вирішується на рівні компанії, адже саме бізнес в цілому постраждає, якщо значні помилки вийдуть до кола клієнтів .

Пізніше Редагувати: Це підштовхнуло мене до раціоналізації своїх конвенцій про іменування своїми веб-продуктами (дякую за запитання). Я визначився з чотирма "середовищами", з тестовим розділенням між qa (мінімальний однорівень лише для функціональності тестування) та стадією (така ж архітектура, що і виробництво, для тестування навантаження / продуктивності / обсягу).

Єдиною реальною різницею в забезпеченні є виробництво / постановка встановлення БД в окрему систему, яку я контролюю, за якими групами знаходяться різні сервери. Qa / dev виконують як веб-сервер, так і db ролі. Збалансування навантаження здійснюється Cloudflare.

У мене також є змінна ENV_NO, яка передається системам, щоб я міг вибрати стільки прикладів "qa" або "staging", скільки мені захочеться.

Отже, щоб налаштувати друге середовище qa, включаючи мою останню резервну копію в прямому ефірі, команди:

git checkout desired-branch/commit for provisioning
ENV_NO=2 bin/provision create qa
# come back after a short lunch

git checkout desired-branch/commit
ENV_NO=2 bin/cap qa deploy
# a minute or two

ENV_NO=2 bin/cap qa db:upload db:restore
# longer than I want once there is a decade of data ("longer" coffee break to traverse a 5.3km ADSL link)

Нарешті, у мене є один додатковий (необов’язковий) сервер під назвою "readonly" як остання сітка безпеки перед ударом об землю. Він надається як система qa, але резервне копіювання та оновлення останніх ночей вимкнено (програмне забезпечення також оновлюється до останньої ночі).

Він використовує підхід "Усі яйця в іншому кошику": він надається з іншим місцеположенням / реєстратором DNS, DNS-хостом, постачальниками системних постачальників послуг. Це кінцева / остання сітка безпеки, тому якщо все загорілося полум'ям, ви можете принаймні дістатись даних до останньої ночі. Сценарії резервування виділяють різницю між різними постачальниками, тому 99% - це той самий, лише прапор лише для читання. Балансир завантаження Cloudflare буде перенаправляти трафік на сайт, який читається тільки в тому випадку, якщо всі сервери в реальному часі вийшли з ладу.

Що стосується внесення змін, то вам пощастить знайти когось, хто просто вислухає вашу професійну думку та впровадить запропоновані зміни.

На моєму досвіді, кожного разу, коли мені доводилося робити серйозні зміни, я мусив обґрунтовувати це з точки зору економії бізнесу. Наприклад, запровадити ReSharper в конвеєр розробки було досить просто, оскільки я зміг сказати щось у відключеному напрямку:

ReSharper коштує близько 50 фунтів на одного розробника. Середня вартість розробника на рік - 40 000 фунтів стерлінгів. ReSharper повинен збільшити продуктивність розробників щонайменше на 20%, враховуючи його повний потенціал. Скажімо, розробник витрачає 75% свого часу фактично на написання коду в IDE. 75% 40k - 30k £. £ 30 000 - це вартість продуктивності розробника. Додатковий відсоток продуктивності (1%) на рік коштує 300 фунтів стерлінгів. Щоб отримати 20% додаткової продуктивності, бізнесу доведеться витратити 6 тис. Фунтів стерлінгів.

Якщо ви повинні поставити це на перспективу бізнесу, ви можете сказати, що ви можете найняти когось іншого і отримати додаткову 20% продуктивність за £ 6 тис., Або ви можете отримати той же результат, витративши 50 фунтів на ліцензію ReSharper. Як тільки цифри стоять перед бізнесом, рішення буде легко прийняти.

Тепер, що стосується ваших запитань щодо наявності декількох середовищ, все, що вам потрібно зробити, - це знайти спосіб розрахувати, скільки це коштує бізнесу щороку, щоб зараз мати ці середовища.

Ви можете попросити своїх колег-розробників відстежувати години, що витрачаються щотижня на налаштування програм для розробки, розгортання тощо. Наприклад, десять годин старшого часу розробника можуть коштувати бізнесу 500 фунтів. Це 10 годин, які можна витратити на розвиток, або щось набагато важливіше. Ви збираєте цифри за певний період часу і забезпечуєте бізнес щорічними витратами.

Я особисто ненавиджу подібну політику, але вона є звичайною, і ми повинні з нею жити.