Skip to content
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension


Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
23 changes: 23 additions & 0 deletions .github/workflows/ci.yml
Original file line number Diff line number Diff line change
@@ -0,0 +1,23 @@
name: ci
on:
push:
branches:
- develop
permissions:
contents: write
jobs:
deploy:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
- uses: actions/setup-python@v4
with:
python-version: 3.x
- uses: actions/cache@v3
with:
key: mkdocs-material-${{ github.ref }}
path: .cache
restore-keys: |
mkdocs-material-
- run: pip install mkdocs-material mkdocs-git-revision-date-localized-plugin mike
- run: mkdocs gh-deploy --force
4 changes: 3 additions & 1 deletion .gitignore
Original file line number Diff line number Diff line change
@@ -1 +1,3 @@
.idea/
.idea/
site/
venv/
485 changes: 29 additions & 456 deletions README.md

Large diffs are not rendered by default.

17 changes: 17 additions & 0 deletions docs/cicd.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,17 @@
### Основы CI/CD

Раньше, когда мир был медленнее, программы выпускались крупными релизами (иногда даже раз в год), которые чаще всего вручную устанавливались на сервер. Исправляющие патчи выпускали быстрее, но тоже не то чтобы очень часто.

В современном мире ситуация значительно изменилась. Наши пользователи не готовы ждать, пока вы наконец-то запилите такую необходимую для них фичу. Они хотят её здесь и сейчас. Разработчики подстроились под эти желания и изменили подход к своей работе. Если мы что-то делаем регулярно, зачем это делать вручную? Если всё есть код, то мы можем делать с ним что угодно, отправлять куда угодно. Так появилась методика непрерывной интеграции и непрерывного развертывания.

Разработчик запушил новую фичу? Пора сделать рутинные действия: получить свежие изменения, запустить юнит-тесты, собрать приложение под нужные платформы, развернуть тестовое окружение и запустить интеграционные тесты. Все этапы прошли успешно? Значит, будем считать, что код стабилен и его можно отправить прямо на продуктив, где пользователи сразу получат такую долгожданную фичу и заметно веселее понесут бизнесу свои деньги. Все эти рутинные действия берет на себя система непрерывной интеграции. От нас требуется только предоставить ей необходимое окружение и предоставить скрипт конвейерной сборки. Всё остальное она берет на себя, активно работая на невидимом фронте, лишь периодически оповещая людей, если что-то пошло не так.

Звучит как идеальный мир, где все счастливы, но, к сожалению, в жизни всё несколько сложнее. Всегда есть перечень «Но» переменной длины, который вносит коррективы. Но сама концепция CI/CD и методология DevOps, к которой она относится, является сейчас крайне популярной и эффективной организацией создания и обновления наших продуктов. Ты найдешь ей применение практически на любом проекте.

#### Jenkins

Дженкинс — один из наиболее популярных серверов непрерывной интеграции. Что его делает таким популярным? Во-первых, он бесплатный и опенсорсный. Во-вторых, он **чрезвычайно** расширяемый благодаря сотням различных плагинов и библиотек. Не нашел нужную? Всегда можно запилить свою, ведь Jenkins написан на нашей любимой Java. Настройку наших конвейеров можно производить прямо на Groovy, что предоставляет нам практически неограниченные возможности.

Из минусов можно отметить откровенно устаревший интерфейс, и понимание, что если что-то пошло не так, в поддержку не напишешь, придется ковыряться самому. Следствие бесплатности, увы.

Однако сделать свои первые шаги и запустить первые конвейеры довольно легко. Просто следуй официальному [гайду](https://www.jenkins.io/doc/pipeline/tour/getting-started/) и очень скоро твоё приложение научится тестировать и собирать само себя. Ну не чудо ли?
28 changes: 28 additions & 0 deletions docs/containers.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,28 @@
### Контейнеры

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

А что, если нам нужно переустановить систему? А что, если нужно это сделать на другой ОС? Со всем этим нам поможет технология упаковки приложений в контейнеры. Контейнеры позволяют нам инкапуслировать всю среду, которая необходима для работы нашей программы, внутри черного ящика. Это значит, что сама основная машина не будет замусориваться бесконечными библиотеками и доп. софтом, всё это будет аккуратно упаковано и не будет никому мешать. Удалил контейнер и вместе с ним уедет в небытие вся его обвязка. Никаких больше проблем с конфликтом версий у разного ПО. Счастье для всех, даром и никто не уйдет обиженным.

Исторически, у джавистов ещё в бородатые времена были сервлеты и контейнеры сервлетов, которые примерно про это, но не совсем. Однако, у всех остальных такого счастья не было и они придумали свои решения этой проблемы. Из тех, что наиболее на слуху, стоит отметить Docker и Kubernetes.

#### Docker

Docker, если по умному, — система по автоматизации и управлению нашими контейнерами. Мы ей даем контейнер, а она его запускает, настраивает и подготавливает к работе. Суть самих контейнеров простая как топор: мы описываем, в специальном формате, что нужно для нашего приложения (ОС, библиотеки и прочее). Весь **минимальный** набор, необходимый для корректной работы нашего приложения. А потом запекаем это как слоеный пирог. Собрал ты контейнер, у которого в основе Ubuntu и радуешься жизни, всё работает. А потом захотел стать модным и заменить убунту на alpine, поменял пару строк в своем файле и снова радуешься жизни. Docker хорош там, где нужно тестовое окружение или окружение для разработчика.

Помни, что готовить докер в продуктиве гораздо сложнее, так как сразу возникает куча вопросов, например, по поводу производительности и безопасности. Для твоих учебных проектов это некритично, но в случае чего-то серьезного, лучше положиться на SRE-инженера / системного администратора.

По учебным материалам обрати внимание на:

- Jeff Nickolof. Docker in Action. Серия «in Action» обычно довольно качественная сжатая (но не чересчур), по самым разным темам. Докер не исключение, если хочешь быстро получить базовые знания, данная книга тебе поможет;
- Официальная документация. Куда уж без документации. Написана хорошо, много полезных примеров и гайдов, не стесняйся туда почаще заглядывать.

После того как ознакомишься с учебными материалами, попробуй упаковать с помощью докера любое своё приложение и задеплоить, например, на Heroku. Гайд по деплою докер-образов в Heroku, можно найти [здесь](https://devcenter.heroku.com/categories/deploying-with-docker).

#### Kubernetes

Один контейнер — это хорошо, это надежно. Но что, если мы поддались волне хайпа и теперь у нас из всех щелей лезут микросервисы? Что, если контейнеров у нас десятки, если не сотни? Как управлять всем этим зоопарком и не сойти с ума? Здесь к нам на помощь придет оркестратор Kubernetes или просто кубер. По самому термину «оркестратор» можно догадаться, что его задача состоит в управлении и контроле за нашим многочисленным зоопарком контейнеров. Он позволяет нам их запускать, заменять на другие, следить за их состоянием, автоматически перезапускать, если кто-то упал и даже автоматически масштабироваться в зависимости от текущей нагрузки.

К сожалению, с большой силой приходит большая головная боль, поэтому обычно с кубером работает специальный человек — SRE-инженер. SRE это такой умный человек, который следует философии DevOps. Если есть желание, можешь ознакомиться с бесплатной [книгой](https://sre.google/sre-book/table-of-contents/) от Google, где описывается их виденье данной профессии.

На начальном этапе тебе достаточно будет знать, что кубер существует, что он классный и его очень трудно готовить без соответствующего опыта.
7 changes: 7 additions & 0 deletions docs/eventually.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,7 @@
### Напутствие

Если ты смог осилить все перечисленные выше темы, можешь собой гордиться (впрочем, гордиться собой можешь при любом удобном случае). В руководстве мы намеренно не расписывали каждый аспект в мельчайших деталях. Его цель — создать для тебя красную нить, которой ты можешь следовать активно смотря по сторонам. Есть ещё десятки важных и интересных тем, с которыми ты обязательно столкнешься. Выбрав карьеру разработчика, ты обречен учиться до конца своей карьеры, так что постарайся расслабиться и получать от этого удовольствие. У тебя обязательно получится!

### Собеседования

Если ты считаешь, что уже готов к официальному трудоустройству, то советуем обратить внимание на данный [Ресурс](https://github.com/enhorse/java-interview). Полагаем, он очень поможет тебе в данном нелегком деле.
Loading