DevOps

Методология DevOps охватывает широкий спектр гибких методов разработки и эксплуатации программного обеспечения. На базовом уровне это включает в себя постоянное развертывание кода, когда новые функции становятся доступными для нескольких сред и серверов, при этом заботясь об управлении исходным кодом приложения или набора приложений и служб.

Чтобы получить более подробное руководство по DevOps, ознакомьтесь с:



Мой опыт

Я взял на себя свою первую роль DevOps, когда был студентом четвертого модуля в Школе программного обеспечения и дизайна Тьюринга. Мне и моей группе было поручено улучшить живое приложение регистрации Тьюринга, которое связывается с другой службой для аутентификации. Приложение было написано на Rails, развернуто в рабочей среде на Heroku и имело доменное имя turing.io.

Будучи студентами, мы имели ограниченный доступ к коду частного репо и к производственной среде на Heroku. Поэтому нам пришлось создать промежуточную среду, которая, по сути, действовала бы как наш «производственный» код, и когда этот код был утвержден, его можно было объединить с активным производственным приложением.

Некоторые функции, касающиеся личной информации, такие как платежи и обработка кредитных карт, должны были быть удалены для подготовки; базу данных также пришлось очистить, чтобы наша промежуточная среда не имела доступа к конфиденциальным производственным данным. Благодаря хорошо написанной документации Heroku у нас не возникло особых проблем с созданием двух новых приложений с доменами herokuapp.com и развертыванием их в производственных средах со словом staging в названии приложения. . Проблема заключалась в том, что после того, как они были запущены, приложения не взаимодействовали так же, как локально в процессе разработки. У нас были перенаправления, хотя мы были уверены, что у нас есть вся информация, необходимая для авторизации приложения, проверенная путем тестирования, изучения параметров и отслеживания журналов Heroku.

Весь этот процесс занял полторы недели и стал источником значительного разочарования для меня и моей пары; мы привыкли отлаживать код и работать с фреймворками с подробными ошибками, а не с этой мистической страной Dev и Ops.

Работа над проектом «браунфилд»

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

Первой задачей было исправить набор тестов, в котором было несколько сбоев, которые нужно было отследить. Этот тип работы над проектом заброшенного месторождения, как правило, доставляет удовольствие, и он был для нас; мы решили большинство тестов за день или два и поняли многие части приложения. Мы также обнаружили некоторые области приложения, в работе которых мы не были уверены. Одной из таких областей был пользовательский гем Ruby, который извлекал данные из службы аутентификации для приложения регистрации. Гем хранил пользовательские данные в файле cookie сеанса в браузере и использовал его для авторизации в основном приложении.

Ошибка

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

Как выяснилось, приложения в домене herokuapp.com не могут устанавливать файлы cookie для *.herokuapp.com..

У обоих наших тестовых приложений были домены herokuapp.com, поэтому файлы cookie в одном не могли быть установлены другим. В процессе разработки приложение работало, потому что сессионные куки ничего не регулировало. Активное производственное приложение также было в чистоте, оно находилось в домене turing.io. Решение было простым: мы установили для приложений собственное доменное имя, и вдруг они заработали как положено!

Что я выучил

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

Несколько советов для новичков

  • Используйте документы Heroku для настройки и развертывания, очень хорошо написанные и поддерживаемые
  • Используйте журналы Heroku для отладки, это даст вам представление о том, что происходит между вашим приложением и сервером.
  • Воспользуйтесь преимуществами команд Heroku CLI Toolbelt, таких как heroku config, для проверки и подтверждения переменных среды в вашем приложении.
  • Используйте Gem Figaro для защиты ваших секретных ключей при деплое на git и heroku.