Что такое Chrome Stable, Beta, Dev и Canary Release?
Каналы Chrome Stable, Beta, Dev, Canary Release
Для каждого программного обеспечения, которое предлагается открыто в разных зданиях, предусмотрен цикл обновления. Самая нестабильная сборка обновляется каждый день до самой стабильной сборки, которая выпускается примерно каждые шесть недель. Эти сборки доступны для всех платформ, на которых работает Chrome, включая Windows, Android и Linux.
Тем не менее, лучшая часть этих сборок заключается в том, что вы можете установить их параллельно на свой компьютер, то есть вы можете иметь Canary Build и стабильную сборку вместе. Поскольку они имеют разные профили, они работают без проблем.
Живут на грани
Если вы хотите попробовать что-то, только что испеченное из духовки, с плохим вкусом, вы можете загрузить эти сборки с сайта download-chromium.appspot.com. Чтобы пойти еще глубже, вы можете выбрать конкретную недавнюю сборку, перейдя к водопаду непрерывной сборки Chromium, посмотрев на число в верхней части под «LKGR», а затем зайдя в это ведро Google Storage и загрузив соответствующую сборку.
Что такое Chrome Canary build?
Эта сборка похожа на запеченную в духовке, но работает. Обновления выпускаются ежедневно и доступны для тестирования конечными пользователями. Вы всегда можете отправить отзыв, и сборка Canary действительно собирает данные, которые отправляются обратно на серверы Google.
Что такое канал Chrome Dev?
Это правильная сборка, если вы хотите увидеть новые функции, появившиеся в Chrome. Эта версия обновляется один или два раза в неделю. Хотя он близок к стабильной версии, он все еще содержит множество ошибок, которые необходимо пройти через тестирование. Так что, если вы в порядке с небольшим количеством ошибок, но хотите, чтобы то, что будет легко, это сборка для использования.
Что такое Chrome Beta канал?
Это стабильная версия канала Dev и содержит наименьшее количество ошибок. Это также общедоступная бета-версия перед финальной сборкой. Многое можно исправить, когда Google получит много откликов от реального использования. Он обновляется примерно каждую неделю, а основные обновления – каждые шесть недель.
Что такое Chrome Stable Channel?
Это идеальное печенье с лучшим вкусом по всему миру. Возможности появятся на этом канале более чем через месяц после стабильного канала. Этот канал проходит полное тестирование, устраняется сбои и обновляется примерно каждые две-три недели для небольших выпусков и каждые шесть недель для основных выпусков.
Dev версия что это
Все мы использовали Google Chrome, так как он самый популярный веб-браузер в мире. Но знаете ли вы, что этот браузер имеет четыре различных версии Chrome?
У Google Chrome есть 4 версии: Стабильная, Бета-версия, Dev и Canary. Google использует каждую из этих версий Chrome для разных целей.
В этой статье вы сможете узнать, для чего предназначена каждая из версий Chrome, а также обо всех различиях, которые их разделяют. После глубокого изучения различий между 4 версиями мы порекомендуем лучшую версию Google Chrome для установки на ваши устройства.
Почему существуют разные версии Google Chrome?
У Google Chrome есть 4 разных версии: Chrome Stable, Chrome Beta, Chrome Dev и Chrome Canary. Приложение для каждой из этих версий Chrome доступно в Google Play, но почему существует так много разных версий одного и того же браузера?
Каждая из этих версий представляет собой состояние на этапе разработки, пока не будет достигнута финальная версия, которая может понравиться всем пользователям.
Перед интеграцией новых функций разработчики должны протестировать их работу в пробной версии приложения. В случае с Google Chrome у разработчиков есть 3 тестовые версии приложения (Beta, Dev и Canary) перед окончательной интеграцией функций в финальную версию, известную как Stable. Таким образом, каждая из версий Google Chrome выполняет свою миссию для правильной разработки веб-браузера.
Google Chrome Stable
Google Chrome Stable – это последняя стабильная версия браузера, которую вы почти наверняка установили на свой мобильный телефон или планшет.
В стабильном Chrome пользователи могут пользоваться всеми новыми функциями браузера без ошибок безопасности или стабильности, поскольку они были протестированы в предыдущих версиях. Если вы хотите легко просматривать Интернет, стабильная версия Google Chrome – это версия, которую вы должны установить на свои мобильные устройства.
Стоит отметить, что стабильная версия обновляется каждые две-три недели, а время ожидания крупных обновлений увеличивается до шести недель.
Google Chrome Beta
Версия, предшествующая стабильной –это Google Chrome Beta, она работает корректно и включает новшества, которые позже будут интегрированы в окончательную версию.
По этой причине для многих это наиболее сбалансированная версия, которую вы можете установить на свой мобильный телефон, поскольку она сочетает в себе хорошую производительность и последние функции Chrome.
Кроме того, если вы используете бета-версию Google Chrome, вам гарантированы постоянные обновления, поскольку приложение обновляется каждую неделю. Для крупных обновлений необходимо подождать около шесть недель.
Пользователи бета-версии могут ознакомиться с новыми функциями на четыре-шесть недель раньше, чем в стабильной версии Chrome. Если вы хотите стать одним из них, вы можете бесплатно загрузить бета-версию Chrome из Play Маркет.
Пользователи могут не только пользоваться новыми функциями, но и сообщать о потенциальных ошибках бета-версии Chrome. Таким образом, разработчики могут исправить их до того, как эти функции будут реализованы в окончательной версии Chrome.
Google Chrome Dev
Google Chrome Dev – это версия Chrome, предназначенная для разработчиков и опытных пользователей, которые тестируют последние обновления, чтобы обнаружить все недостатки для улучшения. Стоит отметить, что Chrome Dev может работать с ошибками, это делает приложение нестабильным.
Хотя эта версия не рекомендуется для повседневного использования, Dev идеально подходит для пользователей, которые хотят протестировать новые функции за девять-двенадцать недель до их официального выпуска.
Это приложение постоянно обновляется с целью, чтобы пользователи оставляли постоянную обратную связь в Google. Если вы хотите заранее протестировать Chrome и не возражаете против использования более нестабильной версии, чем бета-версия, вы можете бесплатно загрузить Google Chrome Dev из Play Маркет.
Google Chrome Canary
Последняя версия Google Chrome – Canary версия, специально разработанная для разработчиков. Выпущенная в 2016 году Chrome Canary является наименее стабильной версией приложения, поэтому Google рекомендует использовать ее только для тестирования. В данной версии браузера функции время от времени появляются и исчезают, что также не делает его идеальным для повседневного использования.
Google Chrome Canary первым получает обновления, поэтому они не работают должным образом. Но не все так плохо, потому что для Canary также характерны постоянные обновления, до семи каждую неделю. Если вы хотите использовать эту версию Google Chrome, скачайте ее бесплатно из магазина приложений Play Маркет.
Какую версию Google Chrome установить?
Лучшая версия Chrome, которую вы можете установить – это стабильная версия, так как вы можете наслаждаться стабильной работой браузера. Хотя вам, возможно, придется немного подождать, чтобы протестировать новые функции, стабильная версия является наиболее рекомендуемой для работы в Интернете.
Производительность, стабильность и безопасность гарантируют, что Google Chrome Stable – это идеальная версия для большинства пользователей.
Обзор Chrome DevTools. Решаем основные задачи веб-разработчика
Мы продолжаем цикл статей об инструментах разработчика — Chrome DevTools. В первых двух частях мы уже познакомились с вкладками Elements, Console, Sources и Network и разобрались с их основными функциями.
Возможности Chrome DevTools огромны. С их помощью можно изменять анимацию, проверять доступность, отлавливать ошибки, следить за производительностью сайта и выполнять многие другие задачи. Но на начальных этапах обучения веб-разработке не обязательно разбираться со всеми функциями. Достаточно знать набор базовых инструментов, который понадобится для решения повседневных задач.
Давайте разберёмся, какие задачи можно решить с помощью Chrome DevTools
Посмотреть, как выглядит страница с телефона и планшета
При создании адаптивных сайтов или веб-приложений полезно знать, как выглядит страница на планшете и мобильных устройствах. С помощью инструментов разработчика вы можете сделать это за несколько секунд. Для этого откройте Chrome Devtools, а затем кликните на иконку Toggle device toolbar в левом углу или нажмите комбинацию Ctrl+Shift+M:
Над страницей появится панель с режимами эмуляции из мобильных устройств и планшетов. По умолчанию панель инструментов открывается в режиме адаптивного окна просмотра. Чтобы изменить область до нужных размеров, задайте ширину или потяните за границы рабочей области. А если хотите увидеть, как страница отображается на конкретных устройствах, например, на iPhone 5, кликните на Responsive и выберите подходящий девайс.
Так выглядит страница в мобильной версии
На этой же панели есть еще одна полезная кнопка — DPR (Device Pixel Ratio). С её помощью проверяют, как выглядят изображения на ретина-дисплеях — экранах с повышенной плотностью. Чтобы посмотреть, как выглядит графика на разных устройствах, измените значение DPR и обновите страницу.
Быстро изменить стили прямо на странице
В процессе разработки бывает удобно менять стили прямо в браузере. Например, чтобы проверить, как выглядит элемент с новыми CSS-правилами, или выровнять его при вёрстке под PixelPerfect.
Менять стили в Chrome DevTools можно во вкладке Elements. Сначала выберите элемент, который хотите изменить. Для этого кликните по нему в дереве DOM или активируйте иконку выбора, а затем прямо на странице нажмите на этот элемент.
Меняем элемент прямо на странице
После этого в разделе Styles добавьте, удалите или поменяйте стилевые правила.
Изменяем стилевые правила для псевдоэлементов
Протестировать блоки на переполнение
Во вкладке Elements можно редактировать не только стили, но и DOM-дерево: добавлять и удалять элементы или блоки, менять текст, управлять атрибутами и классами. Это очень удобно, особенно если нужно протестировать какую-то гипотезу или проверить ошибки в вёрстке.
Одна из задач, выполняемых разработчикам с помощью Chrome DevTools — тестирование вёрстки на переполнение. То есть проверка, как ведут себя блоки и элементы при добавлении контента или изменении размеров страницы. Например, вы можете проверить, не выходит ли текст за рамки блока или не выпадают ли элементы из общего потока.
Популярный среди разработчиков мем и заодно пример того, как не нужно делать: вёрстка не должна ломаться при добавлении новых элементов, увеличении текста или изменении размеров страницы.
Как проверить элемент на переполнение текстом
Во вкладке Elements найдите в DOM-дереве элемент, кликните по нему два раза и добавьте текст:
Добавлять текст можно и на самой странице. Для этого откройте соседнюю вкладку Console, введите команду document.body.contentEditable = true и нажмите Enter. После запуска команды вы сможете нажать на элемент и отредактировать его.
Переполнение родительских блоков
Чтобы проверить, не выпадают ли блоки из потока и сохраняется ли сетка, найдите родителя и ему добавьте несколько дополнительных дочерних элементов. Для этого кликните на одном из таких элементов правой кнопкой мыши и нажмите на Duplicate Element.
Пример переполнения: элементы выпадают из родительского блока.
Узнать, какие файлы подключены, и посмотреть их расположение
Порой разработчикам нужно проверить подключенные к проекту файлы и посмотреть их содержимое. В таких случаях на помощь приходит вкладка Sources:
Слева на панели находятся все загруженные ресурсы. Справа — редактор, в котором можно просмотреть любой из загруженных файлов, в том числе изображения. Здесь же можно редактировать CSS и JavaScript. При этом если вы редактируете скрипты, обязательно сохраняйте изменения с помощью команд Command + S для Mac или Control + S для Windows и Linux. Сохранять правки CSS не нужно, они сразу вступают в силу. Конечно, после перезагрузки страницы всё откатится до начального состояния.
Меняем цвет фона во вкладке Sources
Понять, почему не работают скрипты
Если вы написали код на JavaScript и что-то пошло не так, ищите ошибки с помощью вкладок Console и Sources. Во вкладке Console отображаются сообщения об ошибках с указанием файла и строки, на которых находится баг. Если нажать на этот файл, документ сразу же откроется на нужной строке.
Здесь разработчик добавил лишнюю кавычку. Ошибка на первой строке в документе diseasmap.js
Иногда бывает сложно разобраться, с чем связана ошибка и как её решить — особенно если вы только начали учиться разработке. В таких случаях приходится искать ответ в интернете: на форумах и профессиональных чатах.
Еще один способ найти и отладить ошибку — воспроизвести её. Используйте для этого точки останова, которые приостанавливают код в момент его выполнения.
Как использовать точки останова
Для начала откройте вкладку Sources и выберите файл со скриптом. Затем кликните по номеру строки, на которой вы хотите приостановить выполнение кода. Выбранные точки сразу появятся на панели справа в разделе Breakpoints.
Также можно пойти другим путём: кликните на Event Listener Breakpoints и выберите события, на которых нужно приостановить выполнение кода.
JavaScript выполняется последовательно. Когда Chrome дойдет до точек останова, он остановит выполнение скрипта, и вы сможете отследить, что происходит с кодом. Например, посмотреть значения переменных или разобраться с логикой функций. С этого момента только вы управляете кодом. Можете перейти к следующей точке, шагнуть внутрь функции или отключить точки останова. В этом вам помогут кнопки на панели справа.
Для чего они нужны, пойдем по порядку:
Resume Script Execution — продолжает выполнение скрипта до следующей точки останова. Горячая клавиша F8.
Step over next function call — выполняет строку кода и переходит к следующей функции. Горячая клавиша F10.
Step into next call function call — выполняет строку кода и затем ныряет внутрь функции — на первую строку. Горячая клавиша F11.
Step out of current function — выполняет до конца текущую функцию и останавливается на её последней строке. Горячая клавиша Shift + F11.
Step — по принципу действия похожа на Step into of current function. Но если Step into нужен для того, чтобы попасть внутрь функции, то Step просто выполнит её и покажет результат. Горячая клавиша F9.
Deactivate breakpoints — отключает точки останова. Горячая клавиша Ctrl + F8.
Pause on exceptions — выполнение JavaScript приостанавливается, когда появляется какое-то исключение.
Проверить качество сайта
При разработке сайта важно позаботиться о том, чтобы он быстро загружался и был доступен для пользователей и поисковых систем. С помощью инструмента Lighthouse вы можете протестировать свой сайт на скорость, семантику, доступность, разметку и другие характеристики.
Lighthouse оценивает классические сайты по четырём критериям: производительность, лучшие практики, SEO и доступность. Для сайтов, выполненных по технологии PWA (прогрессивные веб-приложения), добавляется пятый критерий — progressive web app.
Как использовать Lighthouse
Чтобы запустить проверку, перейдите во вкладку Lighthouse и нажмите на кнопку Generate report. Во время тестирования инструмент будет менять размеры браузера, имитировать отключение и подключение интернета и выполнять другие операции.
В конце вы получите оценки качества сайта по 100-балльной шкале: чем выше оценка, тем лучше. При этом на чистоту проверки могут влиять разные факторы, в том числе интернет-соединение и расширения Chrome. Поэтому лучше запускать тест в режиме инкогнито, закрыв остальные вкладки.
Результаты проверки.
Ниже находятся показатели, которые повлияли на оценку, скриншоты поэтапной отрисовки страницы и предложения — что можно улучшить. Например, Lighthouse может предложить оптимизировать картинки и шрифты, включить отложенную загрузку графики, уменьшить неиспользуемый CSS и JavaScript или внести другие изменения. Каждое предложение подробно описано, можно даже перейти на отдельную страницу и прочитать о нём подробнее.
Lighthouse не единственный инструмент для оценки качества сайта. Есть и другие сервисы, например, PageSpeed Insights. Но он хорошо справляется со своей задачей, и его можно можно использовать при работе с сайтами на локальном сервере.
При оптимизации сайта в Chrome DevTools вы также можете использовать вкладку Network. Она поможет проанализировать загрузку страницы, посмотреть приоритет и вес загружаемых ресурсов, а также увидеть другую полезную информацию. Более подробно о ней мы рассказали в статье «Введение в Chrome DevTools. Console, Sources, Network».
Chrome DevTools облегчает процесс разработки. И хотя начинающим разработчикам бывает непросто сразу разобраться во всех инструментах — это и не нужно. Сначала осваивайте базу и читайте документацию. А чтобы научиться применять Chrome DevTools на практике, попробуйте наши интенсивы «HTML и CSS. Адаптивная вёрстка и автоматизация» и «JavaScript. Профессиональная разработка веб-интерфейсов».
MODx Revo workflow. Организация рабочего процесса, контроль версий и деплой
Все основные элементы системы MODX, такие как чанки, шаблоны, сниппеты и т.д, хранятся в БД, из этого появляется проблема осуществления контроля версий за этими элементами, а также сложности с разделением на development и production версии сайта.
Содержание
Введение
На момент написания этой статьи я имел опыт веб-разработки чуть более года. Мне повезло, я начал свой путь в этой сфере именно с MODX Revo, но несмотря на все плюсы этого фреймворка, со временем я начал сталкиваться и с минусами. Пока что я не работал в команде над большими сложными проектами и не знаю как обычно люди справляются с указанными выше сложностями. В интернетах я не нашёл какого-либо конкретного решения, и это поспособствовало созданию своего workflow, который я хочу представить в этой статье. Сразу оговорюсь, я не придумал ничего принципиально нового, а просто собрал разбросанные по интернету куски информации в одно руководство как устроить свой рабочий процесс при работе с MODX Revolution.
Что нам понадобится.
— Git
— npm + Gulp
Для работы я использую IDE PHPStorm.
Development и Production версии сайта
Не буду долго рассуждать и скажу сразу, я предлагаю использовать один экземпляр сайта, в котором мы воспользуемся механизмом контекстов MODX Revo. Стандартный контекст web будет содержать релизную версию сайта. Плюс мы создадим ещё один контекст dev, работу с которым вынесем в поддомен. Таким образом, нам нужно:
— домен example.com, работающий в контексте web
— поддомен dev.example.com, работающий в контексте dev
При деплое мне нужно, чтобы изменения сделанные в контексте dev, каким бы то ни было образом сливались в web.
Создаём контекст dev
Эта часть работы начинается с того момента, когда у вас уже установлен движок и необходимые компоненты и настроены доменные имена, т.е. при обращении по обоим адресам example.com и dev.example.com открывается одна и та же стартовая страница MODX (корневая директория обоих доменов общая).
Теперь заходите в админ-панель → системные настройки → контексты и создайте новый контекст. Ключ укажите dev, имя — как угодно, я назвал Development. В контекстном меню слева у вас появится новый контекст. Первым делом создайте для него ресурс, а потом зайдите в настройки контекста (правой кнопкой по контексту → редактировать → настройки контекста) и задайте настройки
— site_start
— error_page
— unauthorized_page,
указав в них ID созданного ресурса. Это нужно, чтобы система не падала с ошибкой, если при работе в контексте dev не будет найдена какая-либо страница.
прим. Я создал контекст dev (Development) и переименовал стандартный контекст Website на Production, ключ стандартного контекста остался прежним — web.
Теперь в папке core/elements/common/plugins/ (создайте необходимые папки) создайте файл switchContext.php со следующим содержимым
Поясню, что делает плагин. При работе с сайтом через админку, т.е. в контексте mgr, ничего не делает. При работе с фронтальной частью сайта на домене dev.example.com переключает контекст на dev. При работе на фронт-енде на основном домене тоже ничего не делает. Но в случае, если исполнение скрипта каким-то образом попадает в default, то выводит ошибку в лог. Такое может случиться, например, при переносе сайта на новое доменное имя, и это сообщение призвано облегчить жизнь тому разработчику, который будет разбираться, почему после переноса ничего не работает. Когда я проверял описанную здесь схему работы на удалённом сервере, я как раз забыл исправить доменные имена в этом плагине и по ошибке в логе сразу понял что не так. В очередной раз сам себе сказал «Спасибо».
Обратите внимание, в самом конце файла плагина необходимо поставить оператор return, если плагин не должен ничего возвращать, это необходимо для того, чтобы переписать возвращающее значение оператора include, который мы используем при подключении файла плагина.
Через админ-панель создайте новый плагин, который будет подтягивать созданный файл
повесьте запуск плагина на событие OnHandleRequest.
Теперь у нас есть два контекста, как их использовать в дальнейшей разработке будет показано ниже.
Контроль версий
Создаём репозиторий проекта, например на GitHub, при этом в рабочем каталоге будут только файлы и папки, не относящиеся к движку. Примерно так
При этом, мы будем также контролировать файлы, получаемые в результате сборки (assets/web/ и core/elements/web/), чтобы иметь возможность откатиться после неудачного деплоя. Такая структура папок будет объяснена ниже.
Схема работы
Когда я выше говорил о Develpoment и Production версиях, я предложил использовать один экземпляр сайта. Это также предполагает отсутствие его локальной копии (не путать с локальным git-репозиторием проекта). Мы будем править файлы на локальной машине, но при этом в нашем локальном рабочем каталоге будут только файлы и папки, не относящиеся к движку. Мы будем вносить правки в имеющиеся файлы, затем делать upload этих файлов на сайт. После выполнения какой-либо задачи делаем коммит в локальном репозитории, после чего, если нужно, пушим изменения на GitHub, или где вы там собираетесь держать проект.
Теперь я расскажу, как я предлагаю устроить версионирование основных элементов системы — шаблонов, чанков, сниппетов и плагинов, и описать рабочий процесс через IDE PHPStorm в связке с панелью администрирования MODX. В этом нам поможет легендарный pdoTools и используемый им шаблонизатор Fenom.
Как известно, парсер pdoTools позволяет подключать внешние файлы прямо в теле чанка, и именно эта фича лежит в основе всего устройства контроля версий.
Необходимо выставить настройке pdotools_fenom_parser (Использовать Fenom на страницах) значение Да
Компонент pdoTools имеет системную настройку pdotools_elements_path со значением по умолчанию
Собственно разработка ведётся в папке dev/ при этом действует важное правило для всей команды: «Никто и никогда не должен проводить никакие правки в папке web/». При деплое всё содержимое папки dev/ копируется в web/ с помощью Gulp. Папка common/ содержит общие для обоих контекстов файлы, например, плагин переключающий текущий контекст, описанный выше.
Такая структура папок позволяет при подключении внешних файлов при помощи шаблонизатора Fenom использовать значение плейсхолдера [[*context_key]] примерно так
В первой строке мы складываем в переменную $ctx ключ текущего контекста (dev или web), а во второй строке используем это значение в пути к файлу. Это и позволяет иметь две версии сайта на одном движке.
прим. Подключения чанков в файле шаблона
Помимо файлов, содержащих основные элементы системы, нам также нужно вести контроль версий файлов вёрстки и js. Как правило, эти файлы расположены в папке assets/ следующим образом.
По старой схеме предлагаю создать следующую структуру
Связываем ресурсы с шаблонами
Шаблоны создаём в папке core/elements/dev/templates/, в которых подключаем чанки из папки core/elements/dev/chunks, используя синтаксис шаблонизатора Fenom. При этом, создавая файл шаблона, мы также должны создать соответствующий ему шаблон в админ-панели. Только мы не будем создавать статический шаблон, так как не можем указать конкретный путь к файлу, потому что он зависит от контекста, в котором шаблон используется. Вместо этого в теле шаблона мы пропишем одну единственную строку
Таким образом, этот шаблон послужит своеобразным переключателем файла шаблона для ресурсов в различных контекстах.
прим. Подключение файла шаблона
Создаём плагины
При таком подходе разработки следует отдельно оговорить внедрение в систему новых плагинов.
Аналогично ситуации с шаблонами, плагины создаём в папке core/elements/dev/plugins/, в которых пишем логику работы плагина. Далее, заходим в админ-панель и создаём соответствующий ему плагин (НЕ статический!), в котором подключаем файл плагина через include следующим образом
Не забываем, конечно, в админ-панели задать события, на которые вешается плагин. Если нам нужен плагин, общий для обоих контекстов, в переменную context складываем значение «common», как это было сделано в плагине switchContext.
Деплой
Приводу пример gulp файла. Здесь я описал лишь одну задачу для копирования файлов из core/elements/dev в core/elements/web/, остальные таски, наверняка, сможете написать и сами.
т.е. переводим продакшн-файлы в состояние до сборки и начинаем разбираться что не так.
прим. Пример дерева коммитов.
Выше описанное относится к деплою шаблонов, чанков и сниппетов, а также файлов вёрстки, но что же у нас с ресурсами?
А что с ресурсами?
Рассмотрим такую задачу. На сайте есть раздел Новости, со временем количество публикаций стало очень большим и было принято решение создать новый раздел сайта Архив новостей.
В dev контексте вы создаёте соответствующий контейнер, добавляете пару экземпляров архивных новостей, создаёте чанки, если нужно шаблон и т.п. В результате на домене dev.example.com появляется новый раздел. После одобрения заказчиком, вы производите деплой, описанный выше, но нового раздела на продакшене, конечено, не появится, хотя все файлы будут приведены к необходимому виду. Конечно, это произойдёт, потому что созданный раздел (имеется в виду совокупность созданных ресурсов) будет находиться в контексте dev и не будет доступна в контексте web.
— И что делать?
— Копипаст, товарищи, увы.
А точнее перенос. Мы просто переносим созданный раздел в контекст web, а после повторно создаём его копию в dev, чтобы структура dev-версии сайта соответствовала продакшену.
Да, полностью избавиться от копипаста у меня не получилось.
Заключение
Таким образом, мне удалось организовать рабочий процесс, который бы устроил, в первую очередь, меня. В реальной работе эта схема ещё не применялась, поэтому подводных камней пока не обнаружено. Может быть более профессиональный взгляд читателей увидит существенные недостатки, поэтому прошу написать об этом в комментариях. И кстати, это моя первая статья, и я бы хотел узнать насколько доступно и ясно мне удалось изложить свои мысли, буду благодарен за конструктивную критику.
