Компания «Моё дело» прошла путь от маленького стартапа до лидера рынка в своем сегменте. Вместе с ростом компании росла и ее it структура. Инфраструктура эволюционировала космическими темпами, кол-во проектов стремительно росло. Естественно, всем этим необходимо уметь грамотно оркестрировать. Как это делаем мы и во что это превращается мы и хотим вам рассказать.

1. ИнфраструктураИнфраструктура

2. Рождение"Мое Дело"
(MD 0.1.alpha)

3. Инфраструктура"Мое Дело"

4. Основные"подходы"к разработке
• Ручная сборка кода программистами
• Ручной деплой в production
• Скрипты по почте
• Отсутствие возможности отката "версии"
• Отсутствие должного тестирования
• Ручное отключение сервиса на релиз (раз в неделю)

5. Мелкие шалости
(MD 0.2.alpha)

6. Инфраструктура"Мое Дело"

7. Что мы имели на тот момент...
• Терминирование SSL трафика на Nginx
• Частичный перенос бизнес логики на Nginx
Не имели,но очень хотелось :)
• Мониторинг
• Логирование ошибок

8. Подходы к разработке сохранялись :)

9. Первые шаги в большом мире
(MD 1.0.RELEASE)

10. Инфраструктура"Мое Дело"

11. Темная сторона"Мое Дело"
• Распределение нагрузки (IP hash)
• Синхронизация контента между узлами
• Обслуживание узлов "кластера"
• Долгие релизы продолжались :(

12. Светлая сторона"Мое Дело"
• Выделение QA как отдельного направления разработки
• Значительный рост команды
• Каждой команде "по тестовому серверу"
• Новый офис!!!
• Ломались подходы к разработке :)

13. Новая игрушка (Teamcity)
• Версионность сборок (pack)
• Автоматизированная выкладка (deploy)
• Автоматическое тестирование (unit тесты)
• Обслуживание инфраструктуры (maintenance)
• Централизованное хранилище nuget пакетов
• Выключение сервиса "для чужих"

14. Работа над ошибками
(первая двойка в четверти)
(MD 1.0.1.BUGFIX)

15. Сколько времени потребуется
на синхронизацию 1 000 000 файлов
между 2 серверами?

16. Сколько времени потребуется
на синхронизацию 5 000 000 файлов
между 10 серверами?

17. Новая животинка"Мое Дело"
Кто это? монгогрид или гридомонг?

18. Давайте накормим нашего нашу животинку...
И что мы видим???

19. Животинка вдруг выросла,да еще мутировала
Вот теперь это точно породистый реплисетовый гридомонг.

20. Не ошибается лишь тот,
кто ничего не делает
(MD 2.0.RELEASE)

21. Мы снова переехали :)

22. Инфраструктура"Мое Дело"

23. Continious integration
Teamcity

24. Где мы используем Teamcity?
• Прогон Unit тестов
• Build, Pack, Deploy приложения
• Прогон миграций
• Небольшое обслуживание инфраструктуры (Recycle, Server maintenance)
• Continious Inspection (SonarQube)
• Сборка Nuget пакетов
• Сборка npm пакетов
• Прогон автоматизированных тестов (Selenium)

25. Разбираемся с возможностями Teamcity
• MSBuild
• Bash
• Windows CMD
• Powershell
• Plugins (Artifact Deployer, Node.js build runner)
• MetaRunner
• Teamcity Rest API

26. Hot (Re)Deploy
MD 3.0.RELEASE

27. Мы больше не увидим Андрюшу :(

29. Back-endBack-end

30. • CVSC
• Сборка на локальных машинах
• Прямое изменение структуры БД + mail-sharing
• Нет системы логирования
• Нет мониторинга

31. VCS
• SVN (1 repo)

32. VCS
• SVN (1 repo)

33. VCS
• SVN (1 repo)
• TFS (1 repo)

34. VCS
• SVN (1 repo)
• TFS (1 repo)

35. VCS
• SVN (1 repo)
• TFS (1 repo)
• TFS (10-12 repo)

36. VCS
• SVN (1 repo)
• TFS (1 repo)
• TFS (10-12 repo)
• Git (10-12 repo)

37. VCS
• SVN (1 repo)
• TFS (1 repo)
• TFS (10-12 repo)
• Git (10-12 repo)
• Git (50+ repo)

38. Repo
• Функциональные репозитории (бизнес код, общая схема именования
проектов и sln-файлов)
• Нефункциональные репозитории (полезные скрипты, общие
конфигурации codestyle и т.п.)

39. md-ci
• Обновление локальных репозиториев
• Сборка бекенда
• Сборка фронтенда
• Инициализация структуры БД
• Обновление структуры БД
• Маппинг приложений на сайты IIS
• Запуск IIS

44. Continuous Integration

45. TeamCity (http://www.jetbrains.com/teamcity)

46. Continuous Integration

47. Continuous Integration

48. Continuous Integration

49. Continuous Integration

50. Microservices

51. Microservices

52. Database migrations
• ручное редактирование БД иключено
• обновление состояния БД на всех окружениях
• единоразовое выполнение каждого изменения
• строго предустановленный порядок изменений
• получение изменений БД между версиями
• откат БД на более раннюю версию

53. Database migrations
Fluent Migrations
http://www.github.com/schambers/fluentmigrator

54. Database migrations

55. Database migrations

56. Loggly (http://www.loggly.com)

57. NewRelic (http://www.newrelic.com)

59. Front-endFront-end

61. Новорожденный
• Мало скриптов
• Мало стилей
• Js/css файлы лежат вместе с серверным кодом
• Js/css подключаются напрямую в html
• Нет ни ci, ни минификации, файлы загружатся по ftp

63. Мы идем в детский сад
• Резкий рост количества файлов
• Combres - для минификации и бандлов
• Less вместо css
• Js/css файлы все еще в серверном проекте
• Подключение в html через api Combress
• Появляется ci. Файлы пакуются и диплоются вместе с серверным кодом.

65. Школьник
• Нет Combres, Gulp - да
• Backbone
• Ядро статки(вендоры, общие стили, библиотеки и компоненты)
• Клиентский код вынесен из серверного проекта в отдельное место

70. Студент
• Добавили версионность статики и ядра
• Marionette.js
• CDN

72. Невеста
• Для сборки нового кода используется Webpack
• ESnext (ES6)

73. Невеста
• Для сборки нового кода используется Webpack
• ESnext (ES6)
• PostCss

74. Невеста
• Для сборки нового кода используется Webpack
• ESnext (ES6)
• PostCss
• Компонентный подход

75. Невеста
• Для сборки нового кода используется Webpack
• ESnext (ES6)
• PostCss
• Компонентный подход
• MD-framework

76. Невеста
• Для сборки нового кода используется Webpack
• ESnext (ES6)
• PostCss
• Компонентный подход
• MD-framework
• JSCS / Eslint

77. Невеста
• Для сборки нового кода используется Webpack
• ESnext (ES6)
• PostCss
• Компонентный подход
• MD-framework
• JSCS / Eslint
• Ядро 2.0

79. Мы съезжаем
• Отдельный репозиторий и отдельная сборка в TC (back-end и front-end
независимые)
• Скрипты для сборки gulp/webpack - npm пакеты
• Ядро статики - npm пакет
• Npm скрипты

80. npm start

81. Спасибо за внимание!

82. Moё дело
job@moedelo.org