5790
Best PHP chat @phpGeeksJunior - новичкам @laravel_pro - Laravel @golangGeeks - гошка @jobGeeks - вакансии(250000 р/мес) @dbGeeks - базы данных @ebanoePhp - канал не о PHP @jsChat - JS Реклама: https://tinyurl.com/y4jvs7x9 ДР - 28.03.2016
Не сказал бы, что симфони и Yii2 сильно отличаются, там условно за месяц можно натянуть, ну и документация же есть
Читать полностью…
там матрица изнемагаура (отсылка к изенхауру) мне понравилась
прямо жиза)
Не знаю, я сразу фильтр мне нужный ставлю и просто не смотрю такие вакансии
Читать полностью…
Причем что 800 долларов там это типа норм зарплата
Читать полностью…
У тебя уже опыта столько , что другие проблемы) Я лишь только вступил на этот путь)
Читать полностью…
Я когда работу в прошлом году хантил кликал на все , оферы были по зп от 120к до 250к и понятно, что я выбрал
Читать полностью…
И вот тебе выше писали про зп , якобы указать, то тут я бы с ними поспорил.
Читать полностью…
ну и последний вывод
проверку поставки можно делать только после самой поставки, значит
1. pre build checks
2. build
3. deploy в любое окружение
4. проверка в этом самом окружение сервиса
невозможно сделать проверку окружения на этапе билда, без завершения билда и деплоя этого билда куда нибудь для проверки
ну и проверка уже делается не кода, не юнит теста, а сервиса целиком (со всеми зависимостями) или даже продукта снаружи
ну и phpunit это юнит тесты а не проверка всего сервиса целиком
отсюда есть определенное имхо (выстроданно слезами)
у проекта обычно бывают
1. pre build checks (например их можно запускать у pr и если они fail то не позволят жмакать merge, тут как раз лежит проверка code style, статический анализ, success unit tests и тд)
2. build (когда мы билдим то что прошло pre build checks, запуск тут pre build checks опционально) - например когда что то вливают в master
3. deploy (когда мы деплоим то что нам вернула build, это могут быть как docker image, так и tar.gz, и деплоить можно в разные окружения (stage, beta, pre-release или прод) ) - после билда куда нибудь выливаем, ну или перекрестившись на прод
могут быть и другие шаги
например деплой на какое то окружение и потом дергаем какие нибудь ручки api, чтобы убедится не только что нужная версия php
но и дургие сервисы доступны (та же бд)
и что продуктовые действия работают так как ожидалось
а еще деплой на прод может быть не на всех пользователей сразу
а например только на какую то группу пользователей (feature flag) или например выкладка по регионам
но это обычно в очень крупных проектах
все это в один ci/cd процесс не всегда удается вложить, ну или он становится слишком большим и редко бывает прямо комбо
а вообще все мы только пиздим, а деплоим на самом деле вот так /channel/phpGeeks/1572291
@subbotinv имхо ты не очень слышишь что тебе говорят
ты говоришь о разном
я понимаю о чем ты говоришь и где я с тобой не согласен, ты не хочешь этого понимать
возможно я ошибаюсь
я думаю ты пытаешься благими намерениями сделать как можно больше проверок чтобы гарантировать отсутвие багов
но это почти не реально (или слишком дорого)
просто помимо юнит тестов есть и другие тесты(пирамида тестирования и тд) которыми опасные штуки можно на других уровнях вылавливать.
@inheritdoc солидарен с тобой
Вот, о чём я и говорю. Дальше можно не продолжать этот бессмысленный спор
Читать полностью…
Вот тут правильно мыслишь, и на твоём бы месте начал бы откликаться на все, так как проходить собеседования это уже отдельная работа
Читать полностью…
Как будто по yii2 много вакух, чтобы так делать... А других фреймовичков ты не знаешь
Читать полностью…
Я пару месяцев мониторил зарплаты в Грузии, поплакал с зарплаты 800+ долларов и конкуренции с 800 индусами за эти 800 долларов
Читать полностью…
у меня другая проблема
вакансии что мне интересны выше этой вилки
да и получал я больше
а таких в рф почти не осталось
там есть возможность заполнять свое резюме и экспорт в pdf
того что заполнил
все в рф к этой структуре PDF приучены
Убрал опытный, а то это какой-то прикол, а насчет структуры в hh, там какая-то особая структура нужна?
Читать полностью…
ну и отсюда логично заключить что:
1. не возможно сделать pre build checks на docker image который будет в итоге (мы хз что там в итоге, это надо его собрать, а можно ли начинать собирать мы должны сейчас сказать)
2. после того как мы собрали docker image какой смысл его проверять на pre build checks? (в компилируемых языках это еще не возможно, типо как проверить code style в окружение прода)
3. Мы можем лишь делать окружение максимально похожее на прод и проверять код (не окружение) в pre build checks
4. а итоговое решение можно ли деплоить то что мы собрали, оно может приниматься после деплоя куда то и проверки там (как ручным тестированием, так и автоматизированным) у каждой компании тут свои решения, где то никто не смотрит :) - это тоже нормально
концепция имутабельных билдов заключается в следующем
1. build (внутри которого запускали юнит тест, а потом выкосили все dev зависимости)
2. deploy результата билда на какое то окружение (тестовое прод пофиг, например stage.example.com) (опционально)
3. Проверка сервиса в этом окружение куда его отправили (опционально)
4. Если все хорошо то ВАЖНО: deploy результата билда из пункта 1 на боевое окружение example.com (любое другое окружение может быть не прод,а pre-release, alfa,beta и тд)
смысл в том что пункт 4 не деалет новый билд при деплое на другое окружение (в примере боеове)
это вносит другие потенциальные проблемы, но не те что ты озвучил.
концецпия не говорит что надо phpunit запускать внутри image который будет деплоится
phpunit это имхо pre build checks, если проходим значит можно билдить
пример проблемы которой тут есть
что пока проверяли на пункте 3 задачу
кто то сделал другую задачу и сделал билд, прошел тестирование и его влили в основную ветку
а дальше у нас гонка или поезд надо городить (как то решать проблему)
потому что после вкатывания одной из задач, другие билды по правильному надо актуализировать
но это не всегда делают
тут есть кучи вариантов как решать такое
это не silver bullet
а то что ты говоришь
у тебя просто build и deploy вместе (не там разные стадии конечно, но они паравозом и ты хочешь по максимуму проверить перед деплоем куда то)
и на этапе build ты хочешь сделать проверки которые надо делать после деплоя куда то
имхо
Нет, не так. Я с самого начала сказал, что эта концепция не работает. А весь последующий диалог был разъяснением, почему это не работает
Читать полностью…
К слову, я давно хотел закончить. Завтра Пн, надо отдыхать, а не спорить до ночи в чате
Читать полностью…
О тестировании. Писание о Чистоте Кода и Праведности CI
1. В начале было окружение, и окружение было несовершенно.
Ибо одинаковых окружений под солнцем не существует
2. И сказал Программист: Пусть будет тестирование
И отделил он юнит-тесты от интеграционных
3. Юнит-тесты создаёшь прежде билда.
Ибо путь их - очистить мысль разработчика
4. Интеграционные тесты совершаешь после билда.
Чтобы проверить, жив ли образ и работает ли он в мире реальном.
5. И да будет один контейнер - и один процесс его
Многопроцессные контейнеры - мерзость пред DevOps-ами
6. Не возжелай тестировать в ином артефакте, чем тот, что выкатываешь
Ибо иначе ложь войдёт в CI твой.
7. Если тесты пали - не мёржить.
Зелёная галочка да будет знаком благословения
8. А если после мерджа пали - смирись
Ибо ветка твоя была устаревшей, и должен ты исправить её.
9. Концепция что тестили, то и катим свет далекий
Ибо достигнуть его полностью нельзя, но стремиться к нему должно
10. E2E-тесты тяжки и долги, но истинны
Через них познаёшь, работает ли всё вместе, как задумано
11. И помни: AWS падёт, сети падут, даже CI падёт.
Но дисциплина тестирования стоит твёрдо
12. Не возлагай тесты на прод, кроме случаев нужды крайней.
Ибо прод - земля святая, а эксперименты искушение дьявола
13. И да не принесёшь ты страдания релиз-инженерам.
Ибо гнев их быстр, а память долга