В видео уже не буду об этом говорить, расскажу подробнее сейчас: в test ветку обычно заливают фичи, QA ее тестирует, если все ок - заливается в dev (там кстати зачастую еще раз тестируется, хоть и окружения максимально схожи, если не идентичны), если есть баги, задача возвращается на доработку, разработчик доделывает ее в той же ветке, или заводит новую «бажную» ветку, дальше снова подливается в test и так пока задача не будет выполнена. Когда спринт (чаще 2 недели) подходит к концу, все выполненные задачи (они уже наверняка в dev) заливаются в release, опять таки, чтобы тестировщик протестировал, если все ок, это мержится в master/prod/production. Вот такой флоу зачастую.
@@alena_okotchik не всегда так. Очень сильно зависит от правил, которые приняты на проекте. У нас система другая - dev ветка у нас дла раскатки на стенд dev, и там мы делаем все, что посчитаем нужным, даже можем Proof Of Concept проверять. Далее, когда мы в своих разработках уверены, прогнали unit тесты, отгружаем в тест и там раскатывается на тестовые стенды, кваки получают сообщение, что мы выкатили новую версию, и набрасываются на нее. Далее из теста льем в release и на препрод стенд, потом ветка main и раскатываем прод. А вот фикс багов - есть ветка bugfix, по сути - соседняя с dev, с таким же жизненным циклом, за исключением того, что туда летят только фиксы и исправления, найденные не разработчиками (например, тестерами, поддержкой, аналитиками, пользователями).
При отправке данных в репозиторий первое нажатие - это commit, это фиксация изменений, что git о них знает, локально записал, а вот в общий репозиторий еще не положил, второе - собственно, сама отправка, команда push.
C колокольни мидл дотнетщика напишу заметку одну: если у вас jira или github (не гитлаб), то это всегда pull-request, нежели merge request, может бросаться в глаза в зависимости от стека...
Спасибо за все ваши уроки!! Хотелось бы узнать больше зачем нужны ветки test и release.
В видео уже не буду об этом говорить, расскажу подробнее сейчас: в test ветку обычно заливают фичи, QA ее тестирует, если все ок - заливается в dev (там кстати зачастую еще раз тестируется, хоть и окружения максимально схожи, если не идентичны), если есть баги, задача возвращается на доработку, разработчик доделывает ее в той же ветке, или заводит новую «бажную» ветку, дальше снова подливается в test и так пока задача не будет выполнена. Когда спринт (чаще 2 недели) подходит к концу, все выполненные задачи (они уже наверняка в dev) заливаются в release, опять таки, чтобы тестировщик протестировал, если все ок, это мержится в master/prod/production. Вот такой флоу зачастую.
images.app.goo.gl/9GwTejSQvCPQbXGaA вот хорошая картинка
@@alena_okotchik Спасибо большое, теперь намного понятнее!
@@AlexCujba-ye1bv t.me/helperphp присоединяйтесь в чат и спрашивайте там непонятное по мере изучения уроков)
@@alena_okotchik не всегда так. Очень сильно зависит от правил, которые приняты на проекте. У нас система другая - dev ветка у нас дла раскатки на стенд dev, и там мы делаем все, что посчитаем нужным, даже можем Proof Of Concept проверять. Далее, когда мы в своих разработках уверены, прогнали unit тесты, отгружаем в тест и там раскатывается на тестовые стенды, кваки получают сообщение, что мы выкатили новую версию, и набрасываются на нее. Далее из теста льем в release и на препрод стенд, потом ветка main и раскатываем прод.
А вот фикс багов - есть ветка bugfix, по сути - соседняя с dev, с таким же жизненным циклом, за исключением того, что туда летят только фиксы и исправления, найденные не разработчиками (например, тестерами, поддержкой, аналитиками, пользователями).
Спасибо!! Все очень четко и понятно!!
Сделайте пожалуйста уроки по написанию тестов. Как правильно писать тесты PHPUnit.
спасибо за обратную связь!) сделаю чуть попозже :)
При отправке данных в репозиторий первое нажатие - это commit, это фиксация изменений, что git о них знает, локально записал, а вот в общий репозиторий еще не положил, второе - собственно, сама отправка, команда push.
@@java-on-neva3453 в phpstorm да, при учете, что там автоматически git add работает, там зеленым файлы загораются)
C колокольни мидл дотнетщика напишу заметку одну: если у вас jira или github (не гитлаб), то это всегда pull-request, нежели merge request, может бросаться в глаза в зависимости от стека...
@@sealkeen все верно) но суть то одна