Инновационное и устойчивое развитие сложных социально-экономических систем

5-8 февраля 2020, Ставрополь, Ставропольский Государственный Аграрный Университет

Тема: Цифровизация и возможностей спутниковых систем в агропромышленном секторе

Десятая церемония награждения лучших спикеров CFO-Russia.ru

24 января 2020 года Москва, Radisson Collection Moscow

Вручал награды лучшим спикерам 2019 года в категории «Электронный документооборот и повышения эффективности бизнес-процессов» на Церемонии награждения лауреатов премии «Лучший спикер CFO Russia»

https://www.cfo-russia.ru/meropriyatiya/win/ https://www.cfo-russia.ru/video/59289/

Одиннадцатый форум «Внутренний и внешний электронный документооборот»

24-25 октября 2019 года, Москва, Балчуг Кемпински

Модерация второго дня, модерация панельной дискуссии «Роуминг vs мультиоператорность»

https://www.cfo-russia.ru/meropriyatiya/eldoc/archive/51593/

Всемирный Цифровой Саммит по интернету вещей и искусственному интеллекту «IoT & AI World Russia Summit»

1–2 октября 2019 года в Международном выставочном центре «Казань Экспо», г. Казань, Республика Татарстан.

Тема в секции Индустрия 4.0: Гибкая цифровизация для консервативных предприятий

Четвертая встреча дискуссионного клуба «Информационные технологии в промышленности: переход в цифру»

19 сентября 2019 года, Москва, отель «Националь»

Тема: Реализация проектов цифровизации в промышленности

https://www.cfo-russia.ru/meropriyatiya/itindustry/archive/45296/

Всегда следует быть готовым к ошибкам и постоянным улучшениям

Во-первых, ставьте стратегическую цель, не привязываясь к тактике реализации. Во-вторых, делите проект на короткие итерации с готовностью сменить тактику этапа, поменять этапы местами и быть гибкими, не меняя стратегическую цель. Помимо этого, при планировании уделите особое внимание готовности данных для системы, опишите системное окружение и зависимые проекты. В-четвертых, подключайте различные службы для помощи. Например, PR-службу для разъяснения событий проекта и HR-отдел для развития внутренних коммуникаций между сотрудниками. Это поможет вовлечь в проект всех работников компании.

https://www.cfo-russia.ru/stati/index.php?article=54675

Четвертая конференция «Цифровое предприятие»

22-23 августа 2019 года, Москва, Марриотт Новый Арбат

Тема: Развитие цифровых навыков внутри предприятия и практика реализации проектов в условиях меняющихся требований

https://www.cfo-russia.ru/meropriyatiya/digen/archive/49489/

Десятый форум «Внутренний и внешний электронный документооборот»

22-24 мая 2019 года, Москва, отель «Метрополь»

Тема: «Реализация проекта по налаживанию ЭДО между компаниями, объединенными в холдинг». Предпосылки и проблематика проекта, задачи для подрядчика, а также о выборе конкретного решения и системы. Обратил внимание на подход к решению проекта и его хронологию, а также остановился на подходе Plan-Do-Check-Act. В заключение, поделился эффектом от интеграции обществ, возможными рисками в подобных проектах, а также рассказал о планах компании по развитию roadmap-решения.

https://www.cfo-russia.ru/meropriyatiya/eldoc/archive/44479/

Принципы web-разработки через bitbucket

Несколько человек пишут код (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»;
  • от серверов-произведений искусства, которые были настроены год назад человеком, который потом уволился, а теперь никто не может сделать то же самое, поэтому в случае поломки заменить их будет нечем