CI/CD или как настройка проекта влияет на проект в целом, глазами Сениор Девелопер.

Я как Разработчик создаю фичу или делаю ремонт онг же Баг Фикс, кастомный апдейт новых фич всегда очень ограничен временем, по этому время что планируется потратить, время нужно контролировать. Ведь да я также могу улучшать или чинить процессы деплоя кода. ИТОГО ВЫВОД Слегка не доработанный или старый CI/CD это лучше чем его вообще нет. Признаюсь не сразу осознаешь как лучше всего готовить любой новый пирог из кода так, что бы сервак не подгорал, пирог был красивый, а рецепт уникален и передавался далее по своему айти семейному дереву и обрастал изменениями ониже Best Practices. Решаешь проблемы клиентов я по всему миру вижу типичные ошибки и очень схожие методы решения ошибок.

Многие бизнесмены и люди других профессий которым нужен веб-проект, думают сперва только о создании чего-то за не большие деньги и все, дальше деньги уходят в рекламу и это правильно, и увы многие совсем не думают об необходимости обязательных будущих обновлении а также возможных улучшений. И самое главное контролировать продукт и его жизнь, а жизнь у веб продуктов имеет понятие  EOL (Продукт с истёкшим сроком службы) что такое срок служи или как можно потерять свой проект, как говорят нам Best Practices если вы используете функционал который перестали поддерживать и обновлять, тянет за собой в будущем большой ребилд. А ребилд — это во многих случаях, часто нужно создавать все с самого начала, и снова тратить время и деньги. В случае плановых работ или обновление вашего кода для нового сетапа енвайнронмента .ENV время затрат для запуска вашего проекта на любом localhost должно бить в пределах 20 минут и не занимать много часов на подбор версий и установки софта для нужного функционала, в предыдущей статье мы запускали Apache + PHP 7.x на windows благодаря такому софту как openserver. Openserver помогал огромному количество людей печь свои пирожки быстро. Openserver обычно занимает от 5 до 170 гигабайт и лично мне не всегда нужны версии всех серверов и таже ситуация у любых языков програмирования, софт и подключение и базу данных. Тратить время на более важные дела стало бы приятнее.

CI/CD зависело и будет зависеть от айтишников, так как именно айтишники и их выработанные методики годами, и самое главное опыт решать проблемы клиента, дает возможность создавать правильно как внутренние большие задачи или под задачи мелкие таски. Сейчас проекту всегда нужно описывать их решения на современных технологиях и языках, а как мы видим технологии сейчас привели нас всех к массовым обновлениям как языков программирования так и самих компонентов, модулей, плагинов, так и негативные моменты такие как многие перестали поддерживать свой старый но рабочий код под старые версии языков. И очень часто, старые кода без сильного рефакторинга не смогут запуститься или быстро работать в максимальной нагрузке трафика сервер, но и персональные компьютера, стали мощнее — что привело к результату что соответственно пользователь может принят решение молниеностно, быстрота сети после 2020 года дает возможность сделать все, что вам нужно и даже больше быстро, рассмотрим примеры

а) Вот допустим у вас код изменили, или просто умер физически дата центр как такое было пару тройку лет назад, датацентр в Люксембурге, после пожара, увы но пожар датацентре уничтожил большое количество данных и файлов клиентов без возможности их восстановления. Если у вас есть CI/CD, вам не нужно думать даже о пожаре, ваши файлы сохранены а данные актуальны до момента пожара.

б) У вашей фирмы новый сотрудник, ваша компания взяла нового разработчика сайта себе в штат на достаточно старый но рабочий проект. И ему как новому сотруднику нужно подготовить рабочее место айтишника, поднять проект со всеми нужными параметрами и данными если таковы есть, быстро., и наличие документации способствует этому а правильное CD delivering, CI даст возможность сотруднику сделать свою работу и показать результаты не медленнее чем другие члены команды, что уже работают в такой модели годами.

Интересно когда сервер Apache на macbookpro удалят также как это сделали с пакетами PHP в ОС Монтерей!?

Установка Apache на современнице macbook pro стало сложнее с настройками особенно для новичков, но до безумия просто если использовать Docker и процесс установки софта становится очень простой задачей, сделать контейнер и запустить нужные версии языков и сервера на Apache или даже так запустить что то старенькое на какой-то deprecated версии.

Хоть установка веб-сервера Apache и PHP на MacOS не кажется сложной задачей, процесс  установки Apache в более старых версиях сопровождался использовал известный пакетный менеджер BREW, а потом в свою очередь мы поднимали сервер локально.

brew install httpd

То есть в моем MacBook PRO M1 2021 внутренний Apache лично мне попросту нет смысла использовать от слова вообще и лично мне это сильно помешало на старой версии MacBook PRO INTEL 2019. Не нужные настройки или лишние установки им нет места при разработке.

По этому я считаю что на MacOS тоже не обязательно устанавливать APACHE уже это не актуально. У нас есть контейнеризация и Docker App.

Как альтернатива для быстрой установки Apache, вы можете использовать MAMP известное решение.

Самое время правильное перейти на Docker контейнер для быстрой установки Apache любой версии.

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

Так как версия macOS Monterey лишилась пакетов, был удален и сам PHP для которого APACHE как брат близнец пришел с подарком. С приходом PHP версии 8 сама PHP «пыха» стала еще мощнее, сложнее, умнее.
Почему люди не любили PHP программистов, отсутствие строгой типизации как в Java.

Почему не любили PHP программистов, отсутствие строгой типизации как в Java, и возможность сделать достаточно быстро задачу решив таким образом проблемы клиента, для работы со строками и массивами в веб вреде PHP идеален а PHP 8 вобрала в себя все то лучшее что было и есть у соседних языков.

Последний момент, Docker App так сильно растет и подсаживает на платные аккаунты своих пользователей, что у меня стал вопрос, а менеджер пакетов BREW может стать не актуальным ? BREW может стать не актуальным для использования при работе с LAMP/LEMP в сегменте пользователей под МакОс. а может потому, что BREW создавали под Линукс а МакОс все ни как не могла понять как ей себя изменять.

Даешь свободный APACHE всех версий без пакетного менеджера BREW на МакБУК

Я думаю Стив Джобс был бы рад, что он был прав во многом в своих прогнозах и опасениях. И тем не менее пока лично для меня МакБУК 2021 не тормозит от моих задач, замена МакБука 2019 в этом году (2023) помогло преодолеть проблему нехватки ресурсов на одном из моих образов в Докере.