Github enterprise что это

penartur / -Инструкция-.md

У нас появился свой GitHub (пока что без блэкджека и шлюх). Для того, чтобы оценить его, все новые проекты имеет смысл заводить в нём. Разработчикам были отправлены ссылки на регистрацию, все остальные могут свободно смотреть. Аккаунты разработчиков уже созданы, можно воспользоваться восстановлением пароля.

Для полноценной и простой работы надо:

192.168.88.93 mbs.pos #Micro build server

Установить удобный графический клиент GitHub for Windows с http://windows.github.com/
В GitHub for Windows указать адрес GitHub Enterprise https://pos-github.payonline.ru/ и ваши логин/пароль к GitHub Enterprise
Обязательно в git shell (в меню «Пуск») выполняем команды git config —global core.autocrlf true и git config —global pull.ff only

Предлагаю следующую схему работы:

Каждый из разработчиков, работающих над проектом, делает его Fork (в правом верхнем углу на странице репозитория) к себе, и настраивает build server (см. ниже);
Баги/фичи заводятся в вкладке Issues исходного репозитория (на сайте); указываем в Issue ссылку на исходную задачу в Jira (например, заголовок Issue — «SERVICES-123 Добавить в сервис CurrencyExchange поддержку валюты BTC», текст issue — URL задачи в Jira), в исходной задаче в Jira ссылаемся на Issue на гитхабе;
Разработчик, работающий над багом/фичей, создаёт ветку с названием feature-456-btc-support, где 456 – номер issue, btc-support – краткое название ветки (название ветки проверяется выражением /^feature-(\d+)(?:-[a-z0-9]+)+$/ ;
Коммиты должны быть атомарными; каждое изменение – коммит; изменения регулярно синхронизируются на сервер;
После окончания работы над фичей разработчик на странице своего репозитория открывает Pull Request для соответствующей ветки; название Pull Request – вида «Closes #456 (implemented BTC support)» (так pull request будет автоматически связан с issue);
Другой из разработчиков, работающих над этим проектом (или тимлид) по итогам code review принимает или отклоняет pull request. При принятии pull request изменения автоматически мёрджатся в выбранную ветку исходного репозитория (обычно – master), issue автоматически закрывается.

Кроме того, у нас есть build server, реагирующий на все изменения в репозиториях github, который может собирать ваш проект при каждой синхронизации локального репозитория на сервер. Для этого надо:

В настройках репозитория GitHub добавить в Collaborators пользователя PayOnlineAdmin.
В настройках репозитория GitHub в web hooks добавить hook с адресом http://mbs.pos/github/postreceive (в будущем это будет происходить автоматически)

Сейчас это выглядит примерно так.

В связи с тем, что билд-сервер сейчас работает на моей машине, возможны тормоза; от синхронизации до обновления статуса на странице репозитория может проходить достаточно много времени. GitHub сейчас работает на специальной виртуалке it-online, с ним тормозов быть не должно.

Как обновить свой форк?

Перед тем, как вносить изменения в проект, над которым одновременно работает много людей, надо обновить свою версию (так, чтобы в неё пришли изменения, внесённые другими людьми), чтобы при открытии Pull Request не было конфликтов. В будущем этот функционал должен появиться одной кнопкой в GitHub for Windows. А пока что для этого надо залезть в консоль (в GitHub for Windows в правом верхнем углу шестерёнка, нажимаем на ней и выбираем Open a Git shell) и выполнить в ней следующие команды:

# Эти две команды надо выполнить, когда хотите синхронизировать свой форк с основным репозиторием. # Перед этим надо убедиться, что у вас в master нет изменений, не попавших в master основного репозитория; # если есть - надо либо откатить их (rollback), либо открыть на них pull request. # Но если вести всю разработку в feature-ветках, изменений в master быть не должно. git pull upstream master git push origin master # При использовании PowerShell можно обойтись одной командой: git pull upstream master ; git push origin master

git checkout BRANCHNAME — переключает в ветку BRANCH

git checkout -b BRANCHNAME — создаёт новую ветку на основе текущей и переключает в неё

git status — посмотреть, какие файлы изменены (и какие отслеживаются)

git add PATH — добавление файлов для отслеживания (аналогично Include changes в TFS, только на уровне конкретных изменений, а не файлов; по умолчанию все изменения не включены)

git add -A — добавление всех изменений для отслеживания

git diff — посмотреть изменения

git diff —cached — посмотреть изменения отслеживаемых файлов

git commit -m «message» — закоммитить отслеживаемые изменения

git push origin BRANCHNAME — загрузить коммиты в ветке BRANCH на сервер

после принятия pull request

git checkout master (переключаемся на master-ветку)

git pull upstream master ; git push origin master (забираем изменения из master-ветки корневого репозитория в локальный репозиторий и загружаем их в свой репозиторий на сервере)

git branch -D BRANCHNAME (удаляем локальную ветку для старой фичи, если CR закрыт, и все дальнейшие изменения будут вестись только по новым CR / дефектам)

Что такое GitLab, как и для чего он используется

GitLab — это инструмент для хранения и управления репозиториями Git. Он дает возможность выполнять совместную разработку силами нескольких команд, применять обновления кода и откатывать изменения, если это необходимо. Решение может работать на собственном сервере или в облаке. Для обоих случаев существуют полностью бесплатная версия и платные тарифы, стоимость которых зависит от функционала (подробнее о тарифах […]

Эта инструкция — часть курса «Введение в Git».

Смотреть весь курс

Изображение записи

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

В этой статье мы рассмотрим установку бесплатной версии GitLab Community Edition (GitLab CE) на сервер с Ubuntu 20.04 LTS x86_64, сравним GitLab с GitHub, разберемся с возможностями платных и бесплатных версий GitLab и расскажем как пользоваться GitLab. Но для начала подготовим выделенный сервер для разворачивания демо-стенда.

Чтобы создать сервер, откроем панель управления my.selectel.ru и перейдем в меню Серверы и оборудование, затем нажмем кнопку Заказать сервер.

В нашем примере для GitLab используется выделенный сервер фиксированной конфигурации EL09-SSD с процессором Intel Xeon E-2236, 16 Гб оперативной памяти, двух SSD-дисков по 480 Гб и операционной системой Ubuntu 20.04 LTS 64-bit.

После выбора сервера нажимаем кнопку Оплатить сейчас и ожидаем готовности сервера.

Примерно через 2 минуты физический сервер будет готов, а мы пока расскажем о возможностях Gitlab.

Возможности GitLab

Возможности GitLab делятся на следующие категории:

управление (Manage),
планирование (Plan),
создание (Create),
проверка (Verify),
упаковка (Package),
безопасность (Secure),
релизы (Release),
конфигурирование (Configure),
мониторинг (Monitoring),
защита (Defend).

Мы расскажем про основные в каждой категории.

Управление

Аутентификация и авторизация. Двухфакторная аутентификация, интеграция с пользовательскими каталогами (AD/LDAP), гранулярный доступ к объектам в GitLab, поддержка токенов и SSO.
Аналитика. Аналитика продуктивности разработчиков, трекинг выполнения задач группами пользователей.

Планирование

Отслеживание проблем. Контроль за статусом проблем, поддержка дискуссий пользователей для обсуждения проблемы, возможность прикрепления файлов.
Контроль времени. Отчеты по затраченному времени и оценка оставшегося времени на выполнение задач.

Создание

Управление исходным кодом. График коммитов, запросы на слияния веток разработки, интеграция с Jira.
Веб-консоль для редактирования кода. Веб-представление кода в интерфейсе, редактирование кода, синхронизация файлов с исходным кодом.

Проверка

Поддержка процесса Continuous Integration (CI). Встроенные инструменты CI/CD, интеграция с Github, просмотр пайплайнов разработки, онлайн-визуализация HTML-артефактов.
Проверка качества кода и тестирование. Отчеты по качеству кода, юнит-тестам, нагрузочное тестирование, тесты на доступность и юзабилити.

Упаковка

Управление репозиториями. Поддержка репозиториев C/C++, Maven (Java), NPM, NuGet (.NET), Composer (PHP), PyPi (Python) и других.
Управление контейнерами. Поддержка работы с Docker, управление репозиторием через API и вебхуки, приватных контейнерных репозиториев.

Безопасность

Поддержка SAST и DAST. Работа с Static Application Security Testing и Dynamic Application Security Testing включая возможности отчетности.
Сканирование зависимостей и управление уязвимостями. Gitlab поддерживает автоматизированное выявление зависимостей в коде и позволяет строить отчеты по возможным уязвимостям.

Релизы

Поддержка процесса Continuous Delivery (CD). Возможность запуска CI/CD в различных окружениях (Windows, Mac, Linux), поддержка канареечных релизов, обеспечение безопасности пайплайнов.
Оркестрация релизов. Отслеживание релизов, ассоциация релизов с этапами, управление доступом к защищенным окружениям.

Конфигурирование

Управление Kubernetes. Поддержка работы с несколькими кластерами Kubernetes, разворачивание в кластере Kubernetes, управление переменными в зависимости от окружения.
ChatOps и бессерверные вычисления. Разворачивание и другие операции из чата и поддержка выполнения функций через Knative.

Мониторинг

Метрики. Мониторинг производительности приложений, кластеров kubernetes и самого Gitlab с возможностью отправки уведомлений.
Управление инцидентами и логирование. Автоматическое создание инцидентов в случае превышения порогов и отправка логов во внешние системы.

Защита

Web Application Firewall и безопасность контейнеров. Блокировка атак на веб-интерфейс и отслеживание жизненного цикла контейнеров.
Сетевая безопасность. Поддержка микросегментации контейнеров для изоляции потенциально опасных контейнеров и применение политик безопасности.

Полный список возможностей приведен на сайте GitLab. Там же можно узнать подробнее о каждой.

Как установить и настроить GitLab на Ubuntu

Пока вы узнавали о возможностях GitLab, сервер успешно установлен и готов к работе. Подключаемся по SSH к серверу, переходим в директорию /tmp и загружаем установочный скрипт репозиториев GitLab:

# cd /tmp # curl -LO https://packages.gitlab.com/install/repositories/gitlab/gitlab-ce/script.deb.sh

После загрузки скрипта, он необходимо добавить права на его исполнение:

# chmod 777 script.deb.sh

Теперь скрипт готов к исполнению и можно его запускать:

# bash /tmp/script.deb.sh

После установки репозитория, можно запускать менеджер пакетов apt и начинать установку GitLab:

# apt install gitlab-ce

После выполнения установки, появится сообщение о готовности GitLab к работе:

Для доступа к GitLab через веб-интерфейс, его необходимо настроить. Для этого откроем для редактирования конфигурации в файле /etc/gitlab/gitlab.rb и укажем переменной external_url в качестве значения URL-адрес сервера.

# vi /etc/gitlab/gitlab.rb

В нашем демо вместо имени используется IP-адрес.

Теперь, чтобы новая конфигурация вступила в силу, необходимо выполнить реконфигурацию GitLab:

# gitlab-ctl reconfigure

После окончания процесса конфигурации, откроется интерфейс GitLab и запрос на изменения пароля администратора.

После изменения пароля необходимо выполнить вход в GitLab:

GitLab полностью готов к работе и даже имеет тестовый проект.

Однако, GitLab по умолчанию работает по протоколу http. Чтобы переключить его на протокол https, необходимо изменить значения переменных letsencrypt[‘enable’], letsencrypt[‘contact_emails’] и в переменной external_url указать протокол https:

letsencrypt['enable'] = true external_url "https://" letsencrypt['contact_emails'] = ['test@example.com']

После внесения изменений в конфигурацию, выполним реконфигурацию GitLab:

# gitlab-ctl reconfigure

После реконфигурации GitLab, появится возможность подключаться к веб-интерфейсу по протоколу https.

Если GitLab установлен во внутренней сети и к нему требуется доступ извне, одним из вариантов организации такого доступа может быть настройка проксирования на nginx-сервере (или proxy_pass) с установкой на него ключа Let’s Encrypt. В этом случае в настройках GitLab можно спокойно оставлять доступ по протоколу http.

Иногда, при попытке доступа через веб-интерфейс, GitLab возвращает ошибку 502. Причины могут быть разные, но основные это: нехватка оперативной памяти, остановка службы gitlab-workhorse и изменение прав доступа к файлу /var/opt/gitlab/gitlab-workhorse/socket. В первом случае проблему решит добавление оперативной памяти, во втором перезагрузка сервисов GitLab, а в третьем предоставление сервису nginx доступа к файлу.

Как работать с GitLab

Чтобы упростить работу с репозиториями из командной строки, необходимо добавить собственные ssh-ключи в GitLab. Генерируем пару ssh-ключей:

# ssh-keygen -t rsa -f ~/.ssh/gitlab

Следующий шаг — вывод содержимого публичного ключа и его копирование в буфер обмена:

# cat ~/.ssh/gitlab.pub

В интерфейсе GitLab перейдем в раздел Settings:

Далее в раздел SSH Keys, где нужно вставить скопированный ключ. После этого можно нажать Add key.

Появится следующий экран:

На этом настройка к репозиториям через SSH-ключ завершена и пришло время создать новый проект. Для этого достаточно нажать на + в центральной части экрана и далее на New project.

Проекту нужно присвоить имя, а также выбрать тип проекта:

приватный (Private),
внутренний (Internal),
публичный (Public).

В первом случае проект будет доступен только вам, во втором всем пользователям данной инсталляции GitLab, в третьем случаем всем подряд и без авторизации.

Нажимаем на кнопку Create project:

После создания проекта можно перейти к его настройке. Например, на представлении Members в проект можно пригласить новых пользователей с различными ролями: Guest, Reporter, Developer, Maintainer:

Основы GitLab — это работа с репозиториями. Теперь загрузим в этот проект имеющийся на рабочей станции git-репозиторий. Для начала добавим ссылку на удаленный репозиторий:

# git remote add origin git@:root/selectel-test-project.git

Теперь загрузим репозиторий в GitLab:

# git remote add origin git@:root/selectel-test-project.git

Теперь через веб-интерфейс GitLab можно просмотреть исходный код локального репозитория:

GitLab позволяет также загружать исходный код обратно на рабочую станцию. Для этого нужно выполнить следующую команду:

# git clone git@:root/selectel-test-project.git

Другой вариант загрузки — через веб-интерфейс. Для этого на странице проекта необходимо нажать кнопку ↓ и выбрать формат загружаемого архива:

Теперь разберемся, как в GitLab работать с ветками репозитория. По умолчанию работа ведется в ветке master и все предыдущие действия мы выполняли именно в ней. Для реализации изменений и их отслеживание, разработчику важно иметь собственную ветку, код из которой в дальнейшем можно будет передать в master-ветку.

Чтобы создать новую ветку, достаточно в выпадающем меню рядом с символом + нажать на пункт меню New branch:

Новую ветку также можно создать в локальном репозитории Git и затем загрузить её в GitLab. В веб-интерфейсе появится соответствующая запись о новой ветке.

Мы создали в проекте новую ветку development. В меню Settings — Repository можно выбрать ветку, используемую по умолчанию. После выбора нужно нажать на кнопку Save changes.

Поскольку разработка чаще всего ведется в нескольких ветках, в определенный момент времени появится необходимость выполнить их слияние. Cлияние веток — основа GitLab. В GitLab для реализации этого процесса предназначены запросы на слияние (Merge requests). Создадим в локальном репозитории новую ветку и назовем ее staging:

# git checkout -b staging

Создадим новый файл в репозитории и запишем туда произвольный текст:

# vi new-staging.txt

Добавим этот файл к репозиторию:

# git add new-staging.txt

Выполним коммит с комментарием:

# git commit -m "add feature"

И, наконец, загрузим новую ветку в GitLab:

# git push --set-upstream origin staging

Теперь можно проверить наличие новой ветки staging в интерфейсе GitLab. Перейдем в раздел Repository — Branches и обнаружим созданную ветку. Если перейти в нее, там будет созданный на предыдущих шагах файл new-staging.txt.

Перейдем в эту ветку и нажмем кнопку Create merge request:

Здесь нужно указать название слияния, его описание и, при необходимости, выбрать опцию уведомления заинтересованных пользователей. В нижней части этого экрана нужно нажать кнопку Submit merge request:

На следующем экране можно опционально нажать Approve, а затем нажать Merge:

Слияние веток репозитория выполнено.

Чем отличаются GitLab и GitHub

На специальной странице GitLab есть целая таблица сравнения в разрезе тех возможностей, о которых мы рассказывали в начале статьи. Ко всему этому можно добавить, что GitHub появился на 3 года раньше GitLab и является неким стандартом хранения репозиториев решений с открытым исходным кодом. А еще GitHub — полностью облачное решение, GitLab же может работать на локальном сервере или в облаке.

Использование того или иного инструмента обычно основано на предпочтениях людей, принимающих соответствующие решения. С каждым годом GitLab догонял по функционалу GitHub и сейчас уже во многом его превосходит.

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

Какие существуют версии и тарифы GitLab

GitLab имеет две версии — Community Edition (CE) и Enterprise Edition (EE). У первой (именно ее мы устанавливали в этой статье) полностью открытый исходный код, а вторая построена на базе первой, но имеет дополнительные функции, код которых, увы, не открыт для всех желающих. Версия EE также бесплатная в базовой комплектации и производитель рекомендует использовать именно её, если планируется дальнейший переход на платные тарифы.

Линейка тарифов представлена на скриншоте ниже. Цена за пользователя зависит от тех функций, которые включены в подписку.

Ключевой особенностью подписок уровня Premium и Ultimate является поддержка производителя в режиме 24/7. По этой ссылке можно получить полное представление о возможностях каждой из подписок.

Заключение

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

Что такое git push и как его использовать

Новый год, новый GitHub: неограниченные бесплатные приватные репозитории

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

GitHub Free теперь включает в себя неограниченные приватные репозитории. Впервые разработчики могут использовать GitHub для своих проектов, добавляя до трех соавторов в репозиторий бесплатно. Многие разработчики хотят использовать приватные репозитории для того, чтобы работать над сторонними проектами или пробовать что-то приватно, прежде чем публиковать публично. Начиная с сегодняшнего дня, эти и многие другие сценарии возможны на GitHub бесплатно. Общедоступные репозитории остаются бесплатными и включают неограниченное количество соавторов.
GitHub Enterprise — это новый унифицированный продукт для Enterprise Cloud (ранее GitHub Business Cloud) и Enterprise Server (ранее GitHub Enterprise). Организации, которым нужна гибкость в использовании GitHub в облачной или автономной конфигурации, теперь могут получить доступ к обоим по одной цене. А благодаря GitHub Connect эти продукты могут быть надежно связаны между собой, предоставляя гибридный вариант, позволяющий разработчикам без проблем работать в любой среде.

GitHub Pro (ранее GitHub Developer) и GitHub Team также доступны для разработчиков и команд, которым необходимы профессиональные возможности кодинга и совместной работы. И, конечно же, проекты с открытым исходным кодом будут иметь все необходимое для совместной работы над общедоступными репозиториями, включая нашу бесплатную версию GitHub Team.

Являетесь ли вы студентом, который собирается написать свою первую строку кода, или руководителем предприятия с командами по всему миру, мы хотим, чтобы GitHub был для вас лучшим местом для написания кода, совместной работы и общения с мировым сообществом разработчиков. Сегодняшние изменения — это большие инвестиции в будущее GitHub, и мы будем очень рады всем вашим проектам, задуманным и созданным в 2019 году.

Блог компании Microsoft
Программирование
Git
Системы управления версиями
GitHub