Слайд 1Improve the Development Process with DevOps Practices
Vadym Fedorov
Слайд 2Who am I?
Vadym Fedorov < vfedorov@softserveinc.com >
Role: Solutions Architect
Company: SoftServe
Specialization: Development
of the Enterprise Applications in the IT operations management segment.
Technologies and tools: .NET, Python…
Слайд 3Non-stop Battle: Angry Dev vs Ops
DEV
OPS
Release
Complaints
Слайд 4Pandora’s Box
There is no single responsible person who would manage the
product from definition of business requirements to the product release.
The Dev and Ops teams have different success metrics.
Lack of communication between the Dev and Ops teams.
There is a difference between development and target environment configurations.
Slow and long delivery processes with unpredictable delivery date.
Слайд 5Image taken from https://www.scriptrock.com/blog/devops-whats-hype-about/
Слайд 6Evaluate the Current State
The project maturity model
Слайд 7Key Indicator
Project Portability, i.e. an ability to move the project between
different environments and teams.
Project Continuity ensures that a project can be successfully completed even if a team changes.
Time-to-market and cost requires control over your project development, since these are critical elements that directly affect revenue and your position in the market. So make sure you are using effective ways to optimize this business driver.
Слайд 9Ad-hoc
Deployment or development documentation is often outdated if present at all
Developers
manage 3rd-party dependencies manually
No standardized development workplace configuration
Deployment on staging and production environment is fulfilled manually
Lack of knowledge sharing
Low repeatability of the deployment process
Launching a new team requires significant efforts
Слайд 10Defined
Developers keep project documentation and related configuration up-to-date
Dependencies are managed with
a native package platform (PIP, NPM, NuGet, etc.)
Documents describe development environment configuration or prebuild virtual machine with a configured development environment
Team may use a Build and Continuous Integration System, however, the changes in the configuration are applied manually
Knowledge transfer from the development team to the operational team, and between development teams is performed verbally or via documentation
Repeatability of the deployment process is satisfactory
Launching a new team requires significant effort
Слайд 11Repeatable
Regular validation of the deployment and development documentation
Developers work on
an up to date development environment
Environment configuration and deployment procedures are documented in the form of a code deployed to source control
It is possible to track changes: who and when introduced any changes, what version was deployed, on whichdevelopers’ workstation, and other staging and production environment variables
Team uses virtualization
High repeatability of the deployment process
Launching a new team does not require significant effort
Слайд 12Managed
Managed is the highest level of the project state when development and
production environments are aligned with configuration as much as possible:
The number of manual steps on environment deployment is as low as possible
Слайд 14Organizational Changes
There should be one, and only one, manager responsible for
a product or feature development from A to Z: from the stage of requirement gathering to the release date.
The development and operational teams need to share common success indicators focused on the delivery result.
The operations team needs to define requirements for monitoring, log management and disaster recovery, as well as help the development team design a solution that complies with these requirements.
Слайд 15Teams Collaboration Types
Source: http://blog.matthewskelton.net/2013/10/22/what-team-structure-is-right-for-devops-to-flourish/
Слайд 16Teams Collaboration Types
Source: http://blog.matthewskelton.net/2013/10/22/what-team-structure-is-right-for-devops-to-flourish/
Слайд 17Teams Collaboration Types
Source: http://blog.matthewskelton.net/2013/10/22/what-team-structure-is-right-for-devops-to-flourish/
Слайд 18Development Process Changes
The development team should use a development environment that’s
as close to the target environment as possible.
To apply an “infrastructure as code” approach.
To automate quality control and acceptance testing
Слайд 19
“Infrastructure as Code” Approach
Virtual Machine
Provisioner
Scripts
Vagrant
Code
Virtual Machine
Provisioner
Scripts
Production
Code
Same OS, same configuration and same
versions
Ops or DevOps
Dev
Deploy
Слайд 20Delivery Pipeline
“Build Stage”
Execute Unit Test
Code Analysis
Build deployment package
Automated
Acceptance
Testing
Manual testing
Key
showcases
Exploratory testing
Commit
Deploy
Unit & Integration Tests
Functional Tests
Production Monitoring
Слайд 21Tools That are Good to Know
Vagrant: https://docs.vagrantup.com/v2/
Configuration Management and Provisioners:
Chef: https://www.chef.io/chef/
Puppet:
https://puppetlabs.com/
Ansible: http://www.ansible.com/home
Log management and Monitoring
Newrelic: http://newrelic.com/
Loggly: https://www.loggly.com/
Logstash: https://www.elastic.co/products/logstash
Testing:
JMeter: http://jmeter.apache.org/
Selenium: http://www.seleniumhq.org/
Слайд 22Benefits
Avoidance of the human factor
Improvement of the Quality and Repeatability
Saved Time and
Reduced Risks