{"id":32526,"date":"2019-10-31T21:47:32","date_gmt":"2019-10-31T18:47:32","guid":{"rendered":"https:\/\/prohoster.info\/blog\/protsess-razrabotki-i-testirovaniya-s-docker-i-gitlab-ci\/"},"modified":"2019-10-31T21:47:32","modified_gmt":"2019-10-31T18:47:32","slug":"protsess-razrabotki-i-testirovaniya-s-docker-i-gitlab-ci","status":"publish","type":"post","link":"https:\/\/prohoster.info\/en\/blog\/administrirovanie\/protsess-razrabotki-i-testirovaniya-s-docker-i-gitlab-ci","title":{"rendered":"Development and testing process with Docker and Gitlab CI","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

I invite you to review the transcript of Alexander Sigachev's report from Inventos \"The Process of Development and Testing with Docker + Gitlab CI\"<\/strong><\/p>\n

<\/p>\n

Those who are just starting to implement the development and testing process based on Docker + Gitlab CI often ask basic questions. Where to start? How to organize? How to test?<\/p>\n

<\/p>\n

This report is valuable because it provides a structured overview of the development and testing process using Docker and Gitlab CI. The report dates back to 2017. I believe it offers fundamental principles, a methodology, ideas, and practical experience. <\/p>\n

\n

\r\n \"Play\r\n
<\/div>\r\n <\/div><\/center><\/p>\n

For those interested, please read on. <\/a><\/noindex><\/p>\n

<\/p>\n

My name is Alexander Sigachev. I work at Inventos. I will share my experience using Docker and how we are gradually implementing it in our projects.<\/p>\n

<\/p>\n

The topic of the report: The Development Process Using Docker and Gitlab CI. <\/p>\n

<\/p>\n

\"Development<\/p>\n

<\/p>\n

This is my second report on Docker. At the time of my first report, we were only using Docker in Development on developers' machines. The number of employees using Docker was around 2-3 people. Gradually, we gained experience and progressed a bit further. Here is a link to our first report.<\/a><\/noindex>.<\/p>\n

<\/p>\n

What will be covered in this report? We will share our experiences, discussing the pitfalls we've encountered and how we resolved various problems. It wasn't always pretty, but it helped us move forward.<\/p>\n

<\/p>\n

Our motto: Dockerize everything within reach.<\/p>\n

<\/p>\n

\"Development<\/p>\n

<\/p>\n

What problems are we solving?<\/p>\n

<\/p>\n

When there are several teams in a company, a developer is often a shared resource. There are times when a programmer is pulled from one project and assigned to another for a period.<\/p>\n

<\/p>\n

For a developer to quickly get familiarized, they need to download the project source code and launch the environment as quickly as possible to start solving tasks related to the project.<\/p>\n

<\/p>\n

Usually, if starting from scratch, there is little documentation in the project. Information about setup exists only with the veterans. Employees usually configure their workstations within one or two days. To speed this up, we implemented Docker.<\/p>\n

<\/p>\n

The next reason is the standardization of settings in Development. In my experience, developers are always proactive. In one out of five cases, a custom domain is introduced, for example, vasya.dev. Nearby, there is a colleague, Petya, with the domain petya.dev. They develop a website or some component of the system using this domain name.<\/p>\n

<\/p>\n

When the system grows and these domain names start to appear in configurations, a conflict arises in the Development environments, and the website path gets overwritten.<\/p>\n

<\/p>\n

The same happens with database settings. Some people don\u2019t care about security and work with an empty root password. Others, during the MySQL installation, were required to set a password, and it ended up being just '123'. Often, the database configuration changes continuously depending on the developer's commit. Some fix it, some do not. There were tricky solutions when we would take some test configuration and .gitignore<\/code> each developer had to set up the database. This complicated the startup process. In addition to everything else, one needs to remember about the database. The database needs to be initialized, a password should be set, a user must be created, a table should be created, and so on.<\/p>\n

<\/p>\n

Another issue is different versions of libraries. It often happens that a developer works on various projects. There is a legacy project that started five years ago (from 2017 \u2014 editor's note). At the beginning, it started with MySQL 5.5. There are also modern projects where we try to implement more recent versions of MySQL, such as 5.7 or newer (as of 2017 \u2014 editor's note).<\/p>\n

<\/p>\n

Those who work with MySQL know that these libraries come with dependencies. It is quite problematic to run two databases together. At the very least, it is difficult to connect old clients to the new database. This, in turn, creates several problems.<\/p>\n

<\/p>\n

The next problem arises when a developer works on a local machine; they use local resources, local files, and local RAM. All interactions during the development of solutions occur within the confines of a single machine. For example, we might have three backend servers in Production, but the developer saves files in the root directory, from where nginx retrieves files to respond to requests. When such code goes into Production, the file only exists on one of the three servers.<\/p>\n

<\/p>\n

The direction of microservices is currently evolving. We break down our large applications into smaller, interacting components. This allows us to select technologies tailored to specific task stacks. It also helps distribute work and areas of responsibility among developers.<\/p>\n

<\/p>\n

A frontend developer, while working in JS, has little impact on the backend. The backend developer, in our case, develops using Ruby on Rails and does not interfere with the frontend. Interaction occurs via API.<\/p>\n

<\/p>\n

As a bonus, we managed to utilize resources on Staging through Docker. Each project, due to its specifics, required certain configurations. Physically, we needed to allocate either a virtual server for each project and configure them separately, or share a variable environment where projects could influence one another depending on the versions of libraries.<\/p>\n

<\/p>\n

\"Development<\/p>\n

<\/p>\n

Tools. What are we using? <\/p>\n

<\/p>\n