Improve the Development Process with a Dev Ops

  • Slides: 23
Download presentation
Improve the Development Process with a Dev. Ops practices • Vadym Fedorov

Improve the Development Process with a Dev. Ops practices • Vadym Fedorov

Who am I? Vadym Fedorov < vfedorov@softserveinc. com > Role: Solutions Architect Company: Softserve

Who 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… • •

Non-stop battle: Angry Dev vs Ops Release Complaints DEV OPS

Non-stop battle: Angry Dev vs Ops Release Complaints DEV OPS

Pandora’s Box • There is no single responsible person who would manage the product

Pandora’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.

Image taken from https: //www. scriptrock. com/blog/devops-whats-hype-about/

Image taken from https: //www. scriptrock. com/blog/devops-whats-hype-about/

Evaluate the current state • The project maturity model

Evaluate the current state • The project maturity model

Key indicator • Project Portability, i. e. an ability to move the project between

Key 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.

The Project Maturity Model

The Project Maturity Model

Ad-hoc • Deployment or development documentation is often outdated if present at all •

Ad-hoc • Deployment or development documentation is often outdated if present at all • Developers manage 3 rd-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

Defined • Developers keep project documentation and related configuration up-todate • Dependencies are managed

Defined • Developers keep project documentation and related configuration up-todate • Dependencies are managed with a native package platform (PIP, NPM, Nu. Get, 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

Repeatable • Regular validation of the deployment and development documentation • Developers work on

Repeatable • 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

Managed • Managed is the highest level of the project state when development and

Managed • 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

What can be changed to improve?

What can be changed to improve?

Organizational changes • There should be one, and only one, manager responsible for a

Organizational 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.

Teams Collaboration Types Source: http: //blog. matthewskelton. net/2013/10/22/what-teamstructure-is-right-for-devops-to-flourish/

Teams Collaboration Types Source: http: //blog. matthewskelton. net/2013/10/22/what-teamstructure-is-right-for-devops-to-flourish/

Teams Collaboration Types Source: http: //blog. matthewskelton. net/2013/10/22/what-teamstructure-is-right-for-devops-to-flourish/

Teams Collaboration Types Source: http: //blog. matthewskelton. net/2013/10/22/what-teamstructure-is-right-for-devops-to-flourish/

Teams Collaboration Types Source: http: //blog. matthewskelton. net/2013/10/22/what-teamstructure-is-right-for-devops-to-flourish/

Teams Collaboration Types Source: http: //blog. matthewskelton. net/2013/10/22/what-teamstructure-is-right-for-devops-to-flourish/

Development process changes • The development team should use a development environment that’s as

Development 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

“Infrastructure as code” approach Same OS, same configuration and same versions Vagrant Ops or

“Infrastructure as code” approach Same OS, same configuration and same versions Vagrant Ops or Dev. Ops Production Virtual Machine Provisioner Scripts Deploy Code Dev Code

Delivery Pipeline Functional Tests Unit & Integration Tests “Build Stage” Commit • Execute Unit

Delivery Pipeline Functional Tests Unit & Integration Tests “Build Stage” Commit • Execute Unit Test • Code Analysis • Build deployment package Deploy Automated Acceptance Testing Manual testing • Key showcases • Exploratory testing Release Production Monitoring

Tools that are good to know • Vagrant: https: //docs. vagrantup. com/v 2/ •

Tools that are good to know • Vagrant: https: //docs. vagrantup. com/v 2/ • 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/

Benefits • Avoidance of the human factor • Improvement of the Quality and Repeatability

Benefits • Avoidance of the human factor • Improvement of the Quality and Repeatability • Saved Time and Reduced Risks

Thank you! US OFFICES EUROPE OFFICES Austin, TX Fort Myers, FL Lehi, UT Newport

Thank you! US OFFICES EUROPE OFFICES Austin, TX Fort Myers, FL Lehi, UT Newport Beach, CA Waltham, MA Bulgaria Germany Netherlands Poland Russia Sweden Ukraine United Kingdom www. softserveinc. com