Когда я начал развивать направление тестирования в компании Лайв Тайпинг, я не думал, что профдеформация пустит корни так глубоко, что я начну искать баги даже там, где меня не просят. На фоне этого произошло следующее: я не могу работать с приложением Apple Music. Без судорог, разумеется. И без недоумения, как Apple, уважаемая компания, задающая тон в разработке и дизайне, может допускать такие ошибки и не следовать своим же собственным гайдлайнам. Я активно пользуюсь музыкальными сервисами, и сравнение их юзабилити играет далеко не в пользу Apple Music.

В этой публикации я хочу снять камень с души и описать главные недочёты приложения. Пользование им принесло мне достаточно боли, чтобы взяться за статью. И, как выяснилось во время исследования темы, не мне одному.

В данной статье речь пойдет об истории успеха воображаемого новостного портала, счастливым владельцем которого являетесь вы. К счастью, вы уже храните код проекта на GitLab.com и знаете, что для тестирования можно использовать GitLab CI.
Теперь вам интересно, можно ли пойти дальше и использовать CI еще и для развертывания проекта, и если да, то какие возможности при этом открываются.

Чтобы не привязываться к какой-либо конкретной технологии, предположим, что ваше приложение является простым набором HTML-файлов, никакого выполнения кода на сервере, никакой компиляции JS assets. Деплоить будем на Amazon S3.

У автора нет цели дать рецепты для конкретной технологии в этой статье. Наоборот, примеры кода максимально примитивны, чтобы слишком на них не зацикливаться. Смысл в том чтобы вы посмотрели на фичи и принципы работы GitLab CI в действии, а потом применили их для вашей технологии.

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

Однако мне нравится моя работа, и мне не лень покопаться в этих ошибках, чтобы найти их причину. А она, как правило, следующая: кто-то что-то не понял. Разработчик не понял задачу, клиент не понял команду, менеджер не понял смысл проекта, и так далее. Недопонимание ведёт к срыву сроков и бюджетов, к неправильным ожиданиям клиента, к недоумению конечных пользователей и к беспокойному сну менеджера.

Источник недопонимания — отсутствие эффективной коммуникации. Когда её нет, то нельзя построить и эффективную систему назначения и выполнения задач. Своими советами я хочу помочь вам это исправить.