Рубрика: Библиотека

Несколько человек пишут код (php,js,mysql,html). Коммитят это. Push-ают. Код отправляется на сервер Bitbucket.

Почти так. Как правило, в организации командного рабочего процесса есть несколько дополнительных правил.

1. Под каждую отдельную задачу создаётся отдельная ветка разработки.
2. Разработчик по ходу работы никогда не должен пушить коммиты в ветку master. Он пушит их в свою ветку разработки.
3. Когда задача доведена до некоторого итога, создаётся запрос на слияние (merge request, pull request). Либо в какой-то иной форме (хоть устно) обозначается готовность ветки к слиянию. Подробнее: Зачем нужен pull request, если есть push?
4. Предложенная ветка проходит код-ревью, тестирование и какие угодно другие проверки.
5. В каждом конкретном случае должен быть один ответственный человек, принимающий решение о слиянии. Это может быть тимлид, тестировщик, ещё кто-то — как договоритесь.

Далее вся комманда Pull-ами синхронизирует код у себя на машинах;

Команда git pull фактически включает в себя две: git fetch + git merge. С первой обычно не бывает проблем, вторая может застопориться на конфликтах. Я обычно обновляю master, а потом делаю rebase текущей ветки на него

git fetch
# посмотрим, что к нам пришло
git log --oneline --graph --decorate --all

# обновим master
git checkout master
git merge origin/master # или просто git pull

# переставим текущую ветку на новый master. 
# при наличии конфликтов лучше разрешить их сейчас, чем потом при слиянии в master
git checkout myfeature
git rebase master

Как вы будете развертывать приложение — совершенно отдельный вопрос. Если это интерпретируемый код вроде php или js — удобно использовать rsync. Есть более популярный, но гораздо менее надёжный способ развертывания через репозиторий на production-сервере и git-hook. Если доступен только FTP, придётся через FTP.

Стремитесь к тому, чтобы у вас было абсолютно идентичное окружение на всех этапах процесса: разработка, тестирование, staging (если есть), production.

• Одинаковая ОС
• Одинаковые версии всех зависимостей
• Одинаковый способ развертывания, включая конфигурирование
• Одинаковый способ запуска приложения
• Всё вышеописанное должно быть описано хотя бы в некотором документе, а в идеале — в коде.

Так вы страхуете свою команду:

• от (части) багов, которые просачиваются на прод;
• от феномена «works on my machine»;
• от серверов-произведений искусства, которые были настроены год назад человеком, который потом уволился, а теперь никто не может сделать то же самое, поэтому в случае поломки заменить их будет нечем

• Настройка и развертывание проекта c помощью Git
• Зачем нужен pull request, если есть push?

Расположение оборудования в форме латинской буквы «U». В U-образной ячейке станки расставлены подковообразно, согласно последовательности операций. При таком расположении оборудования последняя стадия обработки проходит в непосредственной близости от начальной стадии, поэтому оператору не нужно далеко ходить, чтобы начать выполнение следующего производственного цикла.

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

https://worksection.com/blog/u-shaped-conveyor-cells.html

Just-In-Time — точно вовремя. Cистема управления материалами в производстве, при которой компоненты с предыдущей операции (или от внешнего поставщика) доставляются именно в тот момент, когда они требуются, но не раньше. Данная система ведет к резкому сокращению объема незавершенного производства, материалов и готовой продукции на складах.

Система «точно вовремя» предполагает специфический подход к выбору и оцениванию поставщиков, основанный на работе с узким кругом поставщиков, отбираемых по их способности гарантировать поставку «точно вовремя» комплектующих изделий высокого качества. При этом количество поставщиков сокращается в два и более раз, а с оставшимися поставщиками устанавливаются длительные хозяйственные связи.

Особенности системы JIT. При функционировании системы JIT ничего не производится и запас на производственном участке не пополняется пока конечный продукт не будет реализован или отгружен. Когда конечный продукт «вытянут», для восполнения изъятого «вытягиваются» изделия из предыдущей стадии производства или от поставщиков. Таким образом, система JIT предполагает обеспечение производственного участка всем ассортиментом материалов и комплектующих, в количестве необходимом для производства сборки (изготовления) такого количества производимых изделий на данном участке, которое его покинуло.

Таким образом, отправной точкой для пополнения запаса на производственном участке при реализации системы KANBAN является сигнал, выдаваемый в виде карточки или пустого контейнера по мере его окончания, но при этом на производственном участке есть полностью заполненный контейнер в объеме запаса, достаточного для работы на период пополнения + 10 – 30% (страховой запас). В системе JIT отправной точкой служит отгрузка готового изделия с производственного участка, после которой осуществляется пополнение запаса в объеме, необходимом для производства следующего аналогичного изделия.