Задачи, характерные для больших компаний

1. Унификация дизайна продуктов компании
2. Синхронизация работы нескольких команд
3. Многократное реиспользование кода

Проблема: разработка интерфейса ведется независимыми командами, котырые зачастую работают над схожими задачами.

Только в Почте сущетсвует 4 группы, которые выполняют задачи нескольких продуктовых менеджеров.

Почта

Облако

Варианты решения

Варианты решения

Что будет

b-thumb

vs

b-thumb2

Что нужно, чтобы такую библиотеку было удобно использовать?

Просто...

1. Подключить к новому проекту
2. Разрабатывать
3. Отдать в тестирование
4. Протестировать самим
5. Вписать в штатный релиз-цикл
6. Вписать в экстренный релиз-цикл
7. Включиться в работу

Как сложно подключить библиотеку к проекту?

git submodule

1. Очень сложно контролировать версию
2. А как мержить?
3. Нельзя построить дерево зависимостей

git subtree

1. Испорченный git log
2. Очень медленно
3. Нельзя построить дерево зависимостей

А как просто?

Пакеты

toolkit@0.15.2

И что?

1. Удобный контроль версий
2. Независимая разработка
3. Слабая связь с проектом
4. Обилие пакетных менеджеров

Просто...

• Подключить к новому проекту
• Разрабатывать
• Отдать в тестирование
• Протестировать самим
• Вписать в штатный релиз-цикл
• Вписать в экстренный релиз-цикл
• Включиться в работу

Как просто разрабатывать с пакетами?

Нужна фича из версии 0.14.0

//package.json

"jam": {
	"dependencies": {



	}
}


//package.json

"jam": {
	"dependencies": {
		"toolkit": "0.14.0",
		"callstackjs": "0.4.2",
		"features": "0.1.0"
	}
}

						

Нужны доработки

						
ll data/packages
...
5 18:27 callstackjs
9 11:20 toolkit -> ../../../packages/toolkit/
5 18:27 features
...
						
						

Доработали! Что потом?

git commit

git push

Выкатываем!

"dependencies": {
  "toolkit": "git+ssh://git@gitmrg.ru:toolkit.git#mail-367"
}

						

Радуемся результату на тестовом стенде

Мерж-реквест в основную ветку пакета

Просто...

• Подключить к новому проекту
• Разрабатывать
• Отдать в тестирование
• Протестировать самим
• Вписать в штатный релиз-цикл
• Вписать в экстренный релиз-цикл
• Включиться в работу

Распространение библиотеки

Пакетные менеджеры

• NPM (https://www.npmjs.com/)
• Bower (http://bower.io/)
• Jam (https://github.com/mailru/jam)

Ключевые требования

• Плоское дерево зависимостей
• Установка пакета из GIT
• Поддержка package.json
• Интеграция с Require.js
• Отсутствие "тяжелого" бекенда

Выбрали jam, как переходное решение к npm

Просто...

• Подключить к новому проекту
• Разрабатывать
• Отдать в тестирование
• Протестировать самим
• Вписать в штатный релиз-цикл
• Вписать в экстренный релиз-цикл
• Включиться в работу

Как договориться
с релиз-инженером?

Наиболее простой способ

Изменения осуществялются в рамках библиотеки

Немного усложним

Изменения осуществялются в рамках задачи проекта

Важно согласовать версию и ревизию

Nightmare

Хотфиксим проект

Просто...

• Подключить к новому проекту
• Разрабатывать
• Отдать в тестирование
• Протестировать самим
• Вписать в штатный релиз-цикл
• Вписать в экстренный релиз-цикл
• Включиться в работу

Немного о версионировании

Мы используем semver

(semver.org)

МАЖОРНАЯ. МИНОРНАЯ. ПАТЧ

0.14.17

Публикация пакетов

Backend

(CouchDB)

Действия владельца пакета

							
~/packages/toolkit  $ jam publish
							
						

И это все?

На самом деле нет

							
~/packages/toolkit  $ git commit -am '0.14.17'
~/packages/toolkit  $ git tag 0.14.17
							
						

Автоматизация рутины

Тестирование

Karma + Jasmine

Непрерывная интеграция

Bamboo

Публикация

grunt-contrib-bump

grunt-jam-publisher

Просто...

• Подключить к новому проекту
• Разрабатывать
• Отдать в тестирование
• Протестировать самим
• Вписать в штатный релиз-цикл
• Вписать в экстренный релиз-цикл
• Включиться в работу

Преимущества такого подхода к разработке

Размер не имеет значения

Слабая связанность и переносимость кода

Личная ответственность разработчика