Вопрос 3 сервером решается через партнёрский отдел.
Нам необходимо обновлять 4:
Prod
Prelive
Test
Dev (1 из всех поднятых песочниц)
Тут главное обновление запускать с не большим интервалом, чтобы 1С-Битрикс не успели выпустить минорное обновление (ибо выбрать версию до которой обновляемся они нам до сих пор не дали).
Поскольку у нас более дюжины правок ядра кочуют из версии в версию, то GIT очень здорово помогает оперативно отследить какую правку забыли накатить.
8гб кеша это ещё немного. Я работал в интернет-магазине размером меньше 500Мб, который генерил больше 5Гб кеша ещё в 2010 (за счёт большого количества фильтров).
Тот проект, о котором речь в статье генеровал совершенно сумасшебшее количество кеша, пока мы не перешли на мемкеш.
Вообще файловый кеш — это конечно не очень хорошо.
P.S. не знаю как принималось решение о покупке в данном случае, но уверен, что если бы пришлось писать свой велосипед, то проблема деплоя была бы точно такая же. Параноидальный режим безопасности + потребность в срочных правках представителями Заказчика контента прямо на бою + удалённый Разработчик.
Хотя желание снести всё ударом тактического ядерного заряда не оставляет меня уже более 2 лет…
Примеры .gitignore есть в части про инициацию репозитория. Там примеры для ядра, /local/ и публички (для субмодуля по понятным причинам отдельный .gitignore не нужен был).
В защиту Заказчика хочется сказать, что не все решается волевым решением «перейдём на новый стек технологий Х» — у больших компаний с сотнями тысяч человек персонала есть определённые политики безопасности для внутренних IT решений в которые очень сложно уложить внешний веб проект с внешним же подрядчиком (всё было бы гораздо проще, если бы Разработчик был в штате, ведь тогда была бы машина во внутренней сети и возможно даже SSH/FTP)
Так же хочется напомнить, что есть сегмент малых (начинающих) интернет-проектов. Такие сайты могут жить на виртуальном хостинге, зачастую без SSH, но с возможностью установки GIT (через техподдержку). Владельцы таких сайтов тоже могут пользоваться преимуществами системы контроля версий, хотя до полноценных процессов (вроде git workflow) ещё не скоро дорастут. Им пригодятся такие простые сценарии, я считаю. Мне бы пригодились, когда я начинал. Потому и написал статью.
Но спасибо за ваше мнение! Это действительно очень частный случай. И он от этого лишь выигрывает, мне кажется.
а) правки кода на боевом сервере, минуя репозиторий, норма рабочего процесса (то ли из-за битрикса, то ли «так исторически сложилось»)
Увы, да.
Все проекты, где я работаю постарался перевести на данную схему. Изредка разработчик вносит правку на бою, не закоммитив. Это отклонение от нормы уже.
б) отсутствие нормального доступа к серверам (хотя через веб-морду можно делать практически всё, включая правки кода из пункта а)
о да!
в) у разработчиков не должно быть даже ro доступа к центральному репозиторию или его клону
И вновь да.
Был бы рад познакомиться с вашим опытом.
К сожалению, в таких ситуациях очень заметны проблемы, но не так просто их решать, поскольку всё переплетается в один адский клубок.
Вот это уже обидно, если честно.
Стараешься поделиться с людьми опытом, а в ответ подобное отношение.
Вы же согласитесь, что далеко не все выбирают технологию? И кто-то вынужден работать с php 5.3, а не 7. А кто-то с 1С-Битрикс, а не Symfony/Laravel. Причём я сейчас не о себе, мне-то в общем всё равно.
P.S. если вдруг возникло ощущение, что пост рекламный, увы мне и ах. Не ставил целью и собственно интереса такового не имею (не продаю и не внедряю, сотрудником компании не являюсь).
Надеюсь на ваше снисхождение в связи с тем, что именно мне и пришлось всё это безобразие поднимать. Никого умнее не нашлось.
ИМХО такие коммиты лучше, чем отсутствие контроля версий за состоянием боевого сервера, хаотично изменяющегося под воздействием внешних сил (редакторов контента в том числе).
1) Постепенная модификация процесса.
если вы посмотрите под кат «Порождение ада», то увидите, что ещё совсем недавно процесс выглядел очень отлично от того, что описывается в статье. Возможно в будущем появятся дополнительные изменения (хотя пока особого смысла нет)
2) Потребность в гибкости. Иногда нужны незначительные отклонения от стандартных команд: закоммитить только некоторые файлы/папки, запушить не в ветку с номером тикета, а ветку «TIKET ##### Patch $$» и т.п.
3) к сожалению скрипты мы бы написали для себя, жёстко зашив настройки, и поделиться ими уже не смогли бы ни при каких обстоятельствах (мне и так пришлось немало побороться за эту публикацию). Да и пользы от них было бы мало кому.
Цель данной публикации — набор готовых практических сценариев с максимально простой структурой, каждый шаг которых начинающий пользователь GIT мог бы отладить и осмыслить.
Лично мне этого очень не хватало, когда мы начинали внедрять систему контроля версий.
Это сильно не то же самое, что использовать связку GIT-клиента VisualStudio или GIT GUI и GitHub/Bitbicket в соло-разработке.
Безусловно. На самом деле так же, как и сам cd в общем-то избыточен в каждом коротеньком сценарии.
pwd оставлен «для страховки» если процессом придётсяз аниматься неопытному пользователю. Так сказать «2 раза проверь, 1 раз запулль».
Есть ещё способ через инфицирование. Заходишь на Coursera почитать новый курс про управление проектами или про алготирмы от МИТ/Принстона, а тут взгляд случайно цепляется за надпись вроде Digital Marketing, та заходишь, начинаешь читать и…
Но только это про настоящих маркетологов, а не то, что в этой статье описано (и в целом по РФ распространено). Без обид, коллеги, спрос рождает предложение, понятно что наш рынок ещё не дозрел просто…
Скорее дело в том, что закон сугубо «для внутреннего употребления», чтобы при желании было проще бизнес отжать.
Бизнес у ФБ Российские власти/граждане отжать не смогут ни при каком раскладе, даже если какое-то количество серверов с какой-то информацией зачем-то тут и окажутся.
Ну а если так, то можно просто проигнорить подобное поведения «проклятых буржуев».
Вот резидентам РФ, боюсь, так просто отделаться не удастся.
я думал имелось в виду что выгоднее 5 штук по 4.99 (24.95 в сумме), чем 1 большая по 19.99, например.
Ну и конечно момент с диверсификацией рисков.
Ведь не все купят все части. Т.е. в реальности средний чем будет меньше, чем 24.95.
Т.е. если средний чем будет меньше 19.99, то среднее число покупателей КАЖДОЙ части должно быть не меньше чем число покупателей гипотетической «полной игры». Иначе прибыль будет размазана по частям, но в целом доход будет меньше.
Если же суммарная стоимость частей меньше стоимости пакета, то эта проблема ещё более заметна.
всё сказанное ИМХО. Просто меня смутила эта цифра, вот и решил уточнить.
Тогда надо было написать в статье, что студий было 51.
Кстати, белые цифры на оранжевых секторах (особенно на светлых) очень плохо читаются. 1 на самом узком секторе практически не видно, поэтому казалось, что у вас в некоторых метриках 50, а в некоторых 51 участник.
игра ценой в $24,99 может быть разбита на пять эпизодов, с ценой каждого в $4,99
4,99*5=24,95<24,99
<ЗанудаМод>так-то наоборот выгоднее по частям в вашем примере.
Мелкие транзакции и так проще у людей идут. Так что скидку обычно делают как раз на покупку пакета из всех частей.</ЗанудаМод>
вот такой вариант мне кажется лучше. Потому что кто-то может предложить фичу «сделать все кнопки крупнее», фича уйдёт в этот сервис и пользователь проголосует (например сам), а автор никогда не собирался делать крупные кнопки. Это, может, противоречит идее проекта. А предложивший фичу пользователь просто не знает об этом.
Или предложат исправить баг, который, на самом деле фича, например.
=)
А в целом идея крутая, хочу русский интерфейс и какое-то альтернативное платёжное средство (вебмани, например)
Всегда было интересно как быть, если пользователи голосуют (в том числе рублём) за какую-нибудь фичу, которую разработчик не может реализовать (хоть по техническим, хоть по морально этическим соображениям). Например новый, красивый мимимишный дизайн кнопок, хотя автор просто не умеет рисовать.
Было бы хорошо только видеть это всё не в рамках «ещё одной образовательной площадке» (коих много и так), а в рамках coursera.
МФТИ там свои курсы выкладывали, вот было бы круто и ваши там видеть.
А мне импонирует этот ваш подход.
Это может показаться юношеским максимализмом, но по-моему именно так и должно быть.
Я в своё время правда схожими принципами руководствовался и «не взлетел». Т.е. и правда это может мешать.
Но с морально-этической точки зрения это отличный принцип, мне кажется.
Делать только то, в чём разбираешься, брать деньги за результат, гарантировать качество, отвечать за свои слова…
Т.е. получается любой работодатель может чисто формально мне ответить, что на вакансию претендовало N человек (а место только 1) и собеседование показало, что профессиональные качества всех претендентов (на субъективный взгляд работодателя, естественно, ведь было только собеседование, никаких бумажек и письменных оценок) были на одном уровне. Поэтому они были вынуждены взять случайным образом 1 из N (или 1 из обратившихся).
Они очень опечалены тем, что вынуждены мне отказать, но место всего 1 и просто не могут дать его всем кандидатам (хотя и хотели бы).
Если так, то за этим можно спрятать всё что угодно…
Мне просто один раз отказали с формулировкой «вы слишком квалифицированы для данной вакансии, мы боимся, что вам может стать у нас скучно», хотя казалось бы это моё дело будет мне скучно или нет, ведь я согласился со всеми требованиями вакансии и сказал, что готов к работе.
(но при этом я понимаю опасения работодателя, который боится, что я пересижу у них 1-2 месяца и убегу куда-то где за мои навыки заплатят больше).
Нам необходимо обновлять 4:
Тут главное обновление запускать с не большим интервалом, чтобы 1С-Битрикс не успели выпустить минорное обновление (ибо выбрать версию до которой обновляемся они нам до сих пор не дали).
Поскольку у нас более дюжины правок ядра кочуют из версии в версию, то GIT очень здорово помогает оперативно отследить какую правку забыли накатить.
а вот с БД беда…
Тот проект, о котором речь в статье генеровал совершенно сумасшебшее количество кеша, пока мы не перешли на мемкеш.
Вообще файловый кеш — это конечно не очень хорошо.
P.S. не знаю как принималось решение о покупке в данном случае, но уверен, что если бы пришлось писать свой велосипед, то проблема деплоя была бы точно такая же. Параноидальный режим безопасности + потребность в срочных правках представителями Заказчика контента прямо на бою + удалённый Разработчик.
Хотя желание снести всё ударом тактического ядерного заряда не оставляет меня уже более 2 лет…
В защиту Заказчика хочется сказать, что не все решается волевым решением «перейдём на новый стек технологий Х» — у больших компаний с сотнями тысяч человек персонала есть определённые политики безопасности для внутренних IT решений в которые очень сложно уложить внешний веб проект с внешним же подрядчиком (всё было бы гораздо проще, если бы Разработчик был в штате, ведь тогда была бы машина во внутренней сети и возможно даже SSH/FTP)
Так же хочется напомнить, что есть сегмент малых (начинающих) интернет-проектов. Такие сайты могут жить на виртуальном хостинге, зачастую без SSH, но с возможностью установки GIT (через техподдержку). Владельцы таких сайтов тоже могут пользоваться преимуществами системы контроля версий, хотя до полноценных процессов (вроде git workflow) ещё не скоро дорастут. Им пригодятся такие простые сценарии, я считаю. Мне бы пригодились, когда я начинал. Потому и написал статью.
Но спасибо за ваше мнение! Это действительно очень частный случай. И он от этого лишь выигрывает, мне кажется.
Увы, да.
Все проекты, где я работаю постарался перевести на данную схему. Изредка разработчик вносит правку на бою, не закоммитив. Это отклонение от нормы уже.
о да!
И вновь да.
Был бы рад познакомиться с вашим опытом.
К сожалению, в таких ситуациях очень заметны проблемы, но не так просто их решать, поскольку всё переплетается в один адский клубок.
Вот это уже обидно, если честно.
Стараешься поделиться с людьми опытом, а в ответ подобное отношение.
Вы же согласитесь, что далеко не все выбирают технологию? И кто-то вынужден работать с php 5.3, а не 7. А кто-то с 1С-Битрикс, а не Symfony/Laravel. Причём я сейчас не о себе, мне-то в общем всё равно.
P.S. если вдруг возникло ощущение, что пост рекламный, увы мне и ах. Не ставил целью и собственно интереса такового не имею (не продаю и не внедряю, сотрудником компании не являюсь).
ИМХО такие коммиты лучше, чем отсутствие контроля версий за состоянием боевого сервера, хаотично изменяющегося под воздействием внешних сил (редакторов контента в том числе).
если вы посмотрите под кат «Порождение ада», то увидите, что ещё совсем недавно процесс выглядел очень отлично от того, что описывается в статье. Возможно в будущем появятся дополнительные изменения (хотя пока особого смысла нет)
2) Потребность в гибкости. Иногда нужны незначительные отклонения от стандартных команд: закоммитить только некоторые файлы/папки, запушить не в ветку с номером тикета, а ветку «TIKET ##### Patch $$» и т.п.
3) к сожалению скрипты мы бы написали для себя, жёстко зашив настройки, и поделиться ими уже не смогли бы ни при каких обстоятельствах (мне и так пришлось немало побороться за эту публикацию). Да и пользы от них было бы мало кому.
Цель данной публикации — набор готовых практических сценариев с максимально простой структурой, каждый шаг которых начинающий пользователь GIT мог бы отладить и осмыслить.
Лично мне этого очень не хватало, когда мы начинали внедрять систему контроля версий.
Это сильно не то же самое, что использовать связку GIT-клиента VisualStudio или GIT GUI и GitHub/Bitbicket в соло-разработке.
pwd оставлен «для страховки» если процессом придётсяз аниматься неопытному пользователю. Так сказать «2 раза проверь, 1 раз запулль».
Но только это про настоящих маркетологов, а не то, что в этой статье описано (и в целом по РФ распространено). Без обид, коллеги, спрос рождает предложение, понятно что наш рынок ещё не дозрел просто…
Бизнес у ФБ Российские власти/граждане отжать не смогут ни при каком раскладе, даже если какое-то количество серверов с какой-то информацией зачем-то тут и окажутся.
Ну а если так, то можно просто проигнорить подобное поведения «проклятых буржуев».
Вот резидентам РФ, боюсь, так просто отделаться не удастся.
Ну и конечно момент с диверсификацией рисков.
Ведь не все купят все части. Т.е. в реальности средний чем будет меньше, чем 24.95.
Т.е. если средний чем будет меньше 19.99, то среднее число покупателей КАЖДОЙ части должно быть не меньше чем число покупателей гипотетической «полной игры». Иначе прибыль будет размазана по частям, но в целом доход будет меньше.
Если же суммарная стоимость частей меньше стоимости пакета, то эта проблема ещё более заметна.
всё сказанное ИМХО. Просто меня смутила эта цифра, вот и решил уточнить.
Кстати, белые цифры на оранжевых секторах (особенно на светлых) очень плохо читаются. 1 на самом узком секторе практически не видно, поэтому казалось, что у вас в некоторых метриках 50, а в некоторых 51 участник.
4,99*5=24,95<24,99
<ЗанудаМод>так-то наоборот выгоднее по частям в вашем примере.
Мелкие транзакции и так проще у людей идут. Так что скидку обычно делают как раз на покупку пакета из всех частей.</ЗанудаМод>
21+16+10+4= 51
Если это проценты, то где ещё 49?
Если это студии, то откуда взялась ещё 1? Вы ведь в начале написали:
Или предложат исправить баг, который, на самом деле фича, например.
=)
А в целом идея крутая, хочу русский интерфейс и какое-то альтернативное платёжное средство (вебмани, например)
МФТИ там свои курсы выкладывали, вот было бы круто и ваши там видеть.
Это может показаться юношеским максимализмом, но по-моему именно так и должно быть.
Я в своё время правда схожими принципами руководствовался и «не взлетел». Т.е. и правда это может мешать.
Но с морально-этической точки зрения это отличный принцип, мне кажется.
Делать только то, в чём разбираешься, брать деньги за результат, гарантировать качество, отвечать за свои слова…
Они очень опечалены тем, что вынуждены мне отказать, но место всего 1 и просто не могут дать его всем кандидатам (хотя и хотели бы).
Если так, то за этим можно спрятать всё что угодно…
Мне просто один раз отказали с формулировкой «вы слишком квалифицированы для данной вакансии, мы боимся, что вам может стать у нас скучно», хотя казалось бы это моё дело будет мне скучно или нет, ведь я согласился со всеми требованиями вакансии и сказал, что готов к работе.
(но при этом я понимаю опасения работодателя, который боится, что я пересижу у них 1-2 месяца и убегу куда-то где за мои навыки заплатят больше).