Mission is feasible: how to develop DevOps in a company with many projects
On the benefits of introducing DevOps, many articles have already been written on Habré and other IT resources, and it is not in doubt. This is understandable: creative disorder with sometimes not obvious areas of responsibility for “ordinary” development, where different people are responsible for the code, brunches, test benches, assembly and deployment, and do not really want to go to the “glade” of their colleagues, is opposed to a high level of organization .
In companies with embedded DevOps, developers have more support and can work more efficiently.
')
But it is not enough just to want to work “rightly”, you need to somehow come to this. And here everything is not so simple.
More precisely, it is possible, but this process can easily go only in small companies, where one or two projects are being developed, or when a high level of development culture is initially present in all teams. But what about internal startups where the idea often overtakes the physical and technical capabilities of the company?
When we at Positive Technologies decided to develop DevOps, we ran into dozens of teams that worked on projects both public and non-public. The teams differed greatly in size, using different release models and technological stack. All this did not allow to create a solution on the principle of one size fits all.
At the same time, resources are always limited and they were not enough to introduce DevOps approaches within each team and project. We needed some new approach. And that's what we came up with.
We needed a set of basic DevOps practices that we could quickly adapt to the tasks of any project. To do this, it was necessary to develop templates for building, deployment and test configurations, to ensure the scaling of projects for the many git branches of individual components, as well as a large number of components themselves and their versions.
We managed to solve these problems by transferring the Continuous Integration infrastructure to use a bunch of several tools:
In the course of numerous experiments on real projects, a hierarchy of TeamCity projects and a typical interface for all projects in this system was developed.
The following processes were worked out in detail:
By clicking the picture will open in full size.
All this is good, but there were questions about the introduction of DevOps in all projects of the company.
And what if you combine several dedicated specialists with different core knowledge into one group that can solve the devOps tasks of the entire company?
So the idea of creating a "fire brigade". Now, instead of inventing automation from scratch for each project on their own, employees working on it can order the DevOps service.
As a result, we were able to significantly reduce the cost of training and launching work on the new methodology, as well as reduce the number of possible errors.
The topic of introducing DevOs is extremely interesting, here various approaches are possible. And it is extremely important to meet and share experiences. Usually such events are called “mitaps”.
We are going to do something similar, but not quite in the usual format: we want to gather “devops” and developers in a relaxed atmosphere, to tell the story of building our own DevOps in fast track mode and listen to you, those for whom we did : developers, automators and testers.
We are waiting for you on Op! DevOps! on Friday, October 7 from 3:00 pm to 7:00 pm at the Blacksmith Irish Pub
The event is free, but the number of seats is limited, so you need to register to participate. For this you need to register .
In companies with embedded DevOps, developers have more support and can work more efficiently.
')
But it is not enough just to want to work “rightly”, you need to somehow come to this. And here everything is not so simple.
You can not just take and develop DevOps (c)
More precisely, it is possible, but this process can easily go only in small companies, where one or two projects are being developed, or when a high level of development culture is initially present in all teams. But what about internal startups where the idea often overtakes the physical and technical capabilities of the company?
When we at Positive Technologies decided to develop DevOps, we ran into dozens of teams that worked on projects both public and non-public. The teams differed greatly in size, using different release models and technological stack. All this did not allow to create a solution on the principle of one size fits all.
At the same time, resources are always limited and they were not enough to introduce DevOps approaches within each team and project. We needed some new approach. And that's what we came up with.
The first steps
We needed a set of basic DevOps practices that we could quickly adapt to the tasks of any project. To do this, it was necessary to develop templates for building, deployment and test configurations, to ensure the scaling of projects for the many git branches of individual components, as well as a large number of components themselves and their versions.
We managed to solve these problems by transferring the Continuous Integration infrastructure to use a bunch of several tools:
- TeamCity - Continuous Integration organization system;
- GitLab - storage system source code component products;
- Artifactory is a system for storing collected binary versions of components and products, caching a proxy of external repositories for various package managers (nuget, npm, pip, rails).
In the course of numerous experiments on real projects, a hierarchy of TeamCity projects and a typical interface for all projects in this system was developed.
The following processes were worked out in detail:
- assembly and deployment on test benches;
- running functional and other tests;
- assignment of quality labels to packages (test, stable, ready for distribution to customers);
- publishing release builds to update servers;
- delivery of assemblies and updates to production and many others.
By clicking the picture will open in full size.
What is the result
All this is good, but there were questions about the introduction of DevOps in all projects of the company.
And what if you combine several dedicated specialists with different core knowledge into one group that can solve the devOps tasks of the entire company?
So the idea of creating a "fire brigade". Now, instead of inventing automation from scratch for each project on their own, employees working on it can order the DevOps service.
As a result, we were able to significantly reduce the cost of training and launching work on the new methodology, as well as reduce the number of possible errors.
The topic of introducing DevOs is extremely interesting, here various approaches are possible. And it is extremely important to meet and share experiences. Usually such events are called “mitaps”.
We are going to do something similar, but not quite in the usual format: we want to gather “devops” and developers in a relaxed atmosphere, to tell the story of building our own DevOps in fast track mode and listen to you, those for whom we did : developers, automators and testers.
We are waiting for you on Op! DevOps! on Friday, October 7 from 3:00 pm to 7:00 pm at the Blacksmith Irish Pub
More about the program of the event
No | Topic | Speaker | Brief theses |
|---|---|---|---|
| The first block of reports | |||
| one | Model of Continuous Integration in Positive Technologies [ slides , video ] | Timur Gilmullin | 1) The initial typical schemes offered by DevOps for all projects of the company: Build - Deploy - Testing - Promote. 2) Implementation of the scheme on the examples of our projects in TeamCtiy. 3) What we have come to. General scheme of Continuous Integration: Build - Deploy - Testing - Promote - Publishing - Delivery - Install & Update |
| 2 | SupplyLab - Publish, Deliver, Deploy, Licensing [ Slides , Videos ] | Alexander Pazdnikov | 1) Organization of an open control system for a full cycle of delivery, deployment and licensing to the Customer. 2) Designing a Publishing, Delivery, Deployment and Licensing System - SupplyLab. |
| 3 | The general concept of a SaltStack-based server environment deployment system [ slides , video ] | Dmitry Miroshnichenko | 1) Designing an update system. 2) About SaltStack. |
| four | Tools for creating product distributions [ slides , video ] | Vladimir Selin | 1) What is a large product distribution? 2) Problem: knowledge of the product installation process is owned by a small number of people. 3) Templates + DSL - the solution to all problems! |
| The second block of reports | |||
| five | Organization of workflow in TFS tracker [ slides , video ] | Alexey Soloviev | 1) TFS as a tracker: a brief overview of the features. 2) Structure of a typical Workflow: basic elements. 3) The complexity of customizing WorkFlow to TFS. |
| 6 | vSphereTools - a tool to automate the work with vSphere [ slides , video ] | Timur Gilmullin | 1) VIX API against pysphere. 2) vSphereTools is a set of scripts from DevOps to support work with vSphere and virtual machines. 3) Description of the instrument, its advantages and disadvantages, possible improvements. |
| 7 | TeamCity and character server integration [ slides , video ] | Alexey Soloviev | 1) What is the server debug symbols, its purpose. 2) Debugging information (debugging symbols) - information that the compiler generates on the basis of source codes. Contains information about the names of source files, variables, procedures, functions. 3) Server debug information - the server, the main purpose of which is storage of debug information, its identification and provision of access. |
| eight | Tools for competitive analysis of software products [ slides , video ] | Vladimir Sofin | 1) What is competitive analysis (KA) of software products? 2) Methods and stages of spacecraft. 3) The complexity of the implementation of the various stages of spacecraft. 4) Spacecraft automation tools. |
| The third block of reports | |||
| 9 | Neuro-fuzzy classification of weakly formalized data [ slides , video ] | Timur Gilmullin | 1) The problems of automating the classification of poorly formalized (fuzzy) data. 2) Fuzzy sets and fuzzy measuring scales. 3) Neural network modeling for data classification. 4) FuzzyClassificator tool and its implementation in the Company. 5) Automation of data classification based on TeamCity. |
| ten | From simple to complex: we automate manual test plans [ slides , video ] | Sergey Timchenko | 1) We look around - the usual process of auto-testing. 2) Remove unnecessary - realistic target process. 3) DataDrivenTesting - creating specials. tools for specific scenarios. 4) RobotFramework - what to do if there are too many simple scripts. |
| eleven | Zabbix monitoring system in development and testing processes [ slides , video ] | Alexey Burov | 1) A system for monitoring resources of various departments. 2) Templates and server roles, access control and areas of responsibility. 3) ptzabbixtools - monitoring configuration on target servers. 4) An example of embedding a monitoring system in the development / testing processes. |
| 12 | Automation of load testing in conjunction JMeter + TeamCity + Grafana [ slides , video ] | Ivan Ostanin and Sergey Tikhonov | 1) Description of the old process of littering the test data: how it was before, what's good, what's bad. 2) Influxdb, as a repository of time-series data. 3) Zabbix - load bench monitoring: Windows and Linux agents, active data collection, autodiscovery of virtual machines in esx. 4) Grafana, as a way to turn graphics and dashboards into candy. 5) Automation of the load from users through the web-UI using Jmeter, display of statistics in real time, CI Teamcity. |
| The fourth block of reports | |||
| 13 | CrossPM package manager: simplifying complex dependencies [ slides , video ] | Alexander Kovalev | 1) Difficulties in disentangling cross and nested dependencies. 2) CrossPM package manager. Its features and examples of use. 3) CrossPM and Artifactory package storage integration. |
| 14 | Practical recommendations for using the TestRail system [ slides , video ] | Dmitry Ryltsov and Alexey Vasilyev | 1) Purpose of using TestRail. 2) Entities of the TestRail system. 3) Features of the project. 4) Our solution. 5) TestRail Integration & Customization. |
| 15 | TeamPass - managing access control for service passwords in a team [ slides , video ] | Dmitry Miroshnichenko | 1) What did not suit keepass? 2) The specifics of the company. 3) Solution. |
| sixteen | Community DevOpsHQ [ slides , video ] | Alexander Pazdnikov | 1) About the project DevOpsHQ - a community of automation engineers. 2) pursued goals. 3) Offered tools. 4) Suggested techniques. 5) Ready solutions. |
The event is free, but the number of seats is limited, so you need to register to participate. For this you need to register .
Source: https://habr.com/ru/post/310584/
All Articles