# Company Infrastructure

This project is the home of all the tasks, issues, knowledge base
articles (wiki pages) and scripts that define, describe and manage
or help manage the IT infrastructure of Company Ltd.

## Getting started

* [Set up your environment for work at Company Ltd.](https://

gitlab.com/Company/infrastructure/wikis/env-setup)
* Read the [Infrastructure Overview](https://gitlab.com/Company/
infrastructure/wikis/it-overview) and get familiar with the basics.
(Ie what protocols are used to access the various systems, how to
log in, etc.)
* Configure your IDE to use [.editorconfig](./.editorconfig)
* Get familiar with [code conventions](#code-conventions) and [best
practices](#best-practices)

## Connecting to Company infrastructure

You will need a VPN client and a certificate to get connected to the
main server that hosts the virtual machines, containers. Download
[https://openvpn.net/index.php/open-source/downloads.html](OpenVPN)
and request a certificate from the admin.

## Physical Servers

* [Bootstrap](./_docs/physical_server_bootstrap.md)

## Backup

[./_docs/backup.md](./_docs/backup.md)

## DNS

[./_docs/dns.md](./_docs/dns.md)

### See Also

* [DNS user documentation](https://gitlab.com/Company/company/-/

wikis/DNS-Usage)

## GitLab

A DevOps engineer should be aware of [General guide lines](https://

gitlab.com/Company/company/-/wikis/Development-Process/GitLab-best-
practices),
although not items are followed for the `infrastructure` project.

### Projects
The main 2 projects that are owned by the DevOps team are:
* [`infrastructure`](https://gitlab.com/Company/infrastructure) -
main DevOps repository
* [`jenkins-lib`](https://gitlab.com/Company/jenkins-lib) - Jenkins
librabries

Other teams/projects usually have their own project. The DevOps team
might own some parts of their repositories, for
example [packaging code](https://gitlab.com/Company/Company/-/tree/
master/packaging) in the [Company Agent repository](https://
gitlab.com/Company/Company)

### Labels

* The DevOps team doesn't care much about labels in the merge
requests. Unless they are required for triggering some
automation process.
* When creating an issue, set the following labels if you are aware
of their values:
* `prio:` - priority:
* `urgent` - other activity should be stopped and efforts should
be transferred to this issue
* `high`
* `medium`
* `low`
* `size:` - estimated amount of time needed for the task. Check
the description of the labels for more details.
* `state:`
* `planning` - the requirements for the task are not well
defined yet
* `ready2work` - the information in the issue is enough for
assigned person to start the work
* `doing` - there is active work on the issue
* `review` - the issue has been passed to review
* `blocked` - the issue requires that some another issue or
external process to be completed first
* `suspended` - the work was suspended for whatever reason, e.g.
due to switching to a higher priority tasks
* When starting, finishing or postponing the work on an issue, make
sure that the `state:` label is up-to-date. Also
add a comment that provides more details, for example in case
`state:blocked` the comment should contain the details
about the blocker.

### Merge Requests

* The MR which is not ready for merge should be marked as `Draft`

* Assigning the MR is not required - if the work on an MR is
completed, reassign the corresponding issue to the reviewer.
* Merging rights are granted for limited number of people and depend
on project, for example:
* `infrastructure` - @maxnasonov
* `jenkins-lib` - @maxnasonov
 * `Company` - @b0ti

When not sure, you may look for `Maintainer` or `Owner` roles in
the list of project members.
* In case of [the Company Agent project](https://gitlab.com/Company/
Company), which contains 2 main branches:
* [`master`](https://gitlab.com/Company/Company/-/tree/master) -
for v5
* [`Company-ee4`](https://gitlab.com/Company/Company/-/tree/
Company-ee4) - for v4

, if the issue doesn't explicitly address only a specific major

version (currently, v5 or v4). then there should be 2
MRs to both main branches. Although content of such MRs may look
very similar, it might not be able to be copied easily
and has to be evaluated manually.

## Code Conventions

For indentation size please check [.editorconfig](./.editorconfig)

### Groovy (including Jenkinsfiles)

* Start variable names with a lowercase letter and use camelCase

rather than under_scores
* Groovydoc. Some info:
* https://www.infoworld.com/article/2074120/documenting-groovy-
with-groovydoc.html
* http://docs.groovy-lang.org/docs/next/html/documentation/
#_groovydoc_the_groovy_java_documentation_generator

### Python

* Spaces over tabs

* reStructuredText Doctrings. Some info:
* https://www.python.org/dev/peps/pep-0287/
* https://gist.github.com/jesuGMZ/d83b5e9de7ccc16f71c02adf7d2f3f44

## Best Practices

* Normally user requests via private messages should be asked to

redirect to #DevOps-Help Teams channel. An exception is
communication related to the work you have been already doing and
perhaps related to some GitLab issue.
* As the team who is responsible for adoption of DevOps practices
across the company, we should ensure that the user
requests are kept in line. Do not hesitate to ask users for
clarification. This is pretty common when a user has a
solution in their head for their problem and makes a request to
implement it directly. Users might not be aware of our
best practices, limitations, possible alternatives. We always
should clarify and understand the actual problem.
* Prepare and email daily reports about your activity. The emails
format is not hardly fixed - the report should contain
 list of tasks you are working on and their status. Check out the
reports of your colleagues and create your own based
on that. You may prepare reports manually or by using [script](./
scripts/daily_report_submit.py).
* Internal DevOps documentation should be part of a repository - via
comments or README files. User-facing functionality should
be described on the wiki pages of the relevant GitLab project.
[The company project's wiki](https://gitlab.com/Company/company/-/
wikis/home)
is used for general documentation.
* Documentation is shared responsibility. If existing documentation
is outdated or missing some points, please don't
hesitate to fix it.
* Technical problems normally has many possible solutions. If a
solution works and satisfies the requirements of a
particular task, it still might be not what we should implement.
Always think about "bigger picture", i.e. about the
whole architecture and the place of the solution there.

## Other documentation pages

* [File Recovery](./_docs/file_recovery.md)

## Useful pages

### Essentials

[Infrastructure wiki main page](https://gitlab.com/Company/

infrastructure/wikis)

### Support

[Company Enterprise Support Board](https://Company.co/user/2010/

support_dashboard)
[Company Community Support Board](https://Company.co/support-
tickets)

## FAQ

> How to create/update/remove infrastructure accounts for Company

employee?

* Most of the services relies on Azure SSO. The users are currently
managed in Azure AD by Balazs Ruttkay.
* The users are represented in the infrastructure by [user configs]
(./configs/user) and can be managed by the
[user_manage.py](./scripts/user_manage.py) ([documentation](./
scripts/README.md#user-manage)). Check [examples](./scripts/
README.md#more-examples)
for common usage patterns.