Agile Principles that apply to DevOps 

July 31st, 2017 | Posted by Vidya Vrat in Agile-Scrum | ALM / DevOps - (1 Comments)

Introduction 

DevOps is a new buzzword and it promotes continuous value delivery to the end users. To know more about DevOps read my article DevOps: What, why and how? 

DevOps is a “culture”, where development, test, and operations work together in a collaborative manner to automate delivery of quality software.  DevOps culture develops “production-first mindset”. I.e. applying DevOps ensures that your code is always ready to be deployed to production. 

Agile Manifesto 

Agile manifesto and principles have an influence on DevOps. Let’s review agile manifesto: 

Manifesto for agile software development  

“We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:  

  • Individuals and interactions over processes and tools 
  • Working software over comprehensive documentation 
  • Customer collaboration over contract negotiation 
  • Responding to change over following a plan 

 Agile Principles 

Overall Agile Manifesto has twelve principles and four of those really gels well with DevOps. 

  • Our highest priority is to satisfy the customer through an early and continuous delivery of valuable software. 
  • Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. 
  • Business people and developers must work together daily throughout the project. 
  • Working software is the primary measure of progress. 

How Agile principles apply on DevOps  

  • Our highest priority is to satisfy the customer through an early and continuous delivery of valuable software. 

  When a team adapts the DevOps culture then team works   together to deliver a high-quality software to the end users consistently over and over.  

  • Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.DevOps promotes short delivery cycles over long delivery cycles. Short delivery cycles have small amount of change which is far easier to deploy and test and detect impact of changes.
     
  • Business people and developers must work together daily throughout the project.DevOps enable the business people to have look at the product early and provide candid feedback. DevOps also provides an easy and effective way of adding approval step in the CI/CD pipeline where business / product owner can approve changes for deployment to other environments.
     
  • Working software is the primary measure of progress.At the end business values working software having reliable feature delivered on time to end users. DevOps practices enable the software development teams to deliver working software on time and provided proper channel for feedback between various stages of the DevOps workflow.
     

, ,

DevOps, What , Why & How

June 7th, 2017 | Posted by Vidya Vrat in ALM / DevOps - (1 Comments)

What DevOps is not?

DevOps is not a “Packaged Solution”. I.e.  You cannot buy and install it.

What is DevOps?

“DevOps is the union of people, process, and products to enable continuous delivery of value to our end users.” – Donovan Brown, MSFT

DevOps is a “culture”, where development, test, and operations work together in a collaborative manner to automate delivery of quality software.  DevOps culture develops “production-first mindset”. I.e. applying DevOps ensures that your code is always ready to be deployed to production.

Why DevOps?

First thing DevOps offers is that, it breaks the “Wall of Confusion” between development and operations team. These two teams have different agenda and expectations when it comes to software delivery and deployment.

DevOps breaks the wall of confusion between teams and fosters better communication and collaboration throughout the application development lifecycle and results into better visibility and small frequent deployments together.

DevOps Benefits and ROI – Source, Forrester Research Inc.

  • Improved IT operations efficiency. Saving 50% of allocated IT operations support.
  • Improved developer productivity with faster, automated release processes. Developers saw a 15% improvement in productivity.
  • Improved tester productivity with faster, automated release processes. 20% productivity gain with their deployment of the Microsoft DevOps solution.
  • Faster recovery from failures and reduction in release risk. Reduce time-to-resolution per incident by 2 hours.
  • Reduced cycle time by as much as 99% and more frequent deployments. Increased customer satisfaction and also gained new business.
  • Faster speed-to-market for new features, products, and services for customers. 20x more, leading to increased sales.
  • Improved release quality. Successful releases with a reduction in errors increase in release reliability, and less time on remediation of release errors.

How to apply DevOps?

Prime objective of DevOps is to “quickly ship the highest quality software to the end customers”. To make this happen DevOps needs to be implemented across all the phases of software development and delivery.

DevOps workflow from planning to release

The workflow model below shows how teams go through four phases and contribute towards DevOps adoption.

Plan – Backlog represents well-defined and prioritized user stories with proper acceptance criteria etc.

Develop & Test – Development will include good quality code written, debugged, code reviewed, checked-in including unit test coverage as appropriate. Testing will include verifying the user story’s acceptance criteria, possibly followed by performance and integration tests etc.

Release – Whenever a new version is ready and a sprint end, an automated process is used for deployment.

Monitor and Learn – After release team can gather information related to how customers use the application /services and continue to monitor health of application.

Collaboration – Building code and running unit tests on each check-in small or big ensures that code is ready to be deployed. Then, deploying it to at-least production like environment and successfully performing tests there ensures that Dev and Production are in collaboration.

DevOps Automation

One major key aspect of DevOps is automation of software build, test, and deploy. DevOps automation enables continuous value delivery.  Let’s see the DevOps Automation process workflow.

Development – This is where a developer writes code in their local development environment.

Version Control – This is version control team uses to check-in code to the repository. E.g. Git, TFS, SVN etc.

Build and Unit Testing – This is where DevOps Continuous Integration (CI) takes place. At this step, code will build with latest checked-in code and latest packages and dependencies as applicable. If there are unit tests then all unit tests will be executed to ensure that there are no collateral damages caused within the code base.

If Build fails then a notification will be sent to the developer who submitted the build. Many teams have various policies and channels set up for this. For example, a bug is created with details when a build fails and team’s slack channel will receive notification when a build fails.

Automated Acceptance Testing – If build succeeds then a set of acceptance tests can be executed automatically to verify that code is working fine.

Any failure in an acceptance test will trigger a feedback initiated to the team and process will again start from beginning.

User Acceptance Test – Passed automated acceptance tests ensures and triggers the code to be promoted to UAT.

Release – Upon passing UAT, code can be released to any environment or production or production like environment. Manual push of code to production is known as Continuous Delivery (CD).

DevOps Toolchain

DevOps is technology agnostic and any development environment on any platform can fully adopt DevOps culture and can continuously deliver quality software to their customers. Here some SDLC phases and tools which will fit in and can help to setup end-to-end DevOps pipeline for your technology and platform of choice.

Planning and Analysis

  • Capturing and tracking (TFS, VSTS, JIRA, ServiceNow.
  • Documentation or Wiki page (Microsoft Teams, SharePoint, Confluence.
  • Collaboration (Slack, HipChat, Microsoft Teams).

Design and Development

  • SCM (TFS, VSTS, Subversion, Git, Mercurial.
  • IDE (Eclipse, IntelliJ, Visual Studio).

Build and Release (CI/CD)

  • Repository management (Artifactory, Nuget, Nexus).
  • Build tools (MSBuild, Jenkins, Bamboo).
  • Configuration management (Chef, Puppet, Ansible).
  • Cloud (AWS, Azure,OpenStack).
  • Containers (Docker).

Integration and Testing

  • Source code verification (SonarQube).
  • Security testing (HP Fortify).
  • Functional testing (MSTest, NUnit, JUnit, Cucumber, Selenium).
  • Performance testing (SOASTA, Apache Test Bench, Microsoft Load and Performance Test).

,

Agile for .NET development teams

May 7th, 2015 | Posted by Vidya Vrat in .NET | Agile-Scrum - (0 Comments)

Watch YouTube Video Here…

Abstract

Agile is a software development methodology which I becoming popular day by day. It defines the mind set of many software development teams working across the globe. This article will walk you through the entire agile-scrum process and how as a developer you can contribute in agile way and deliver value. BTW, agile means ability to move quickly.

Agenda

  • Life Cycle of a Developer
  • Barriers to value delivery
  • Agile Adoption
  • Plan Driven Vs. Value Driven
  • Agile Manifesto
  • Scrum – End-to-End Process
  • Agile Estimation
  • Scrum Status Board
  • Agile Tools
  • Conclusion

Life Cycle of a Developer

1st interaction a developer have is with BA, they are responsible to document, track and describe the user requirements. But many times there are gaps in understanding the needs; which causes issue by various means.  Image below shows what user wanted and what happened when it is implemented.

Stop the blame game

In many team settings, a developer is considered to be responsible for everything, right from understanding requirements to code to support testing, help in deployment and then resolve production issues. Well, I always believed that entire software development is a team effort. But at the end, in most cases developers bear most of the blame. So its no longer a Developer’s responsibility to own everything rather team owns it.

Team Barriers = Value Delivery Impediments

All .NET Development teams want to deliver value but on realistic grounds what are barriers which stops a team to deliver value.

Every team has dependency within and on people outside, the communication gap and lack of understanding of common goal is the root cause of Value Delivery Impediments.

Impact of Team Barriers

Well, most of the issues any software teams runs into has following outcomes:

Increased Cycle Times – This means that you have to work longer to get work completed.

Increased costs – More time means more money.

Dissatisfied users & Stakeholders – End user missed the milestone of feature being available and so it raises concerns for stakeholders as well.

Lost value opportunities – You are potentially not going to have more work from same client.

Agile Adoption

 

Agile-Scrum is most widely accepted methodology of Agile development. Term scrum is taken from sport rugby in which whole team works get the possession of the ball.

Plan Driven Vs Value Driven

 

Plan Driven (waterfall approach) is an old school which defines software development life cycle. Many teams are still doing that though but in waterfall plan takes precedence over value.

Value Driven (agile approach) is new way of building software, it gels teams, stakeholders and user very well and help them team receive early feedback and fail fast.

Manifesto for Agile Development

17+ people gathered in a ski resort and they came up with agile manifesto.

Understanding Type of Backlogs

In agile-scrum there are two type of backlogs

  1. Product backlog
  2. Sprint backlog

Product backlog is larger list of work items (in agile world known as User Stories), it is like a “Functional Specification Document” or System Requirement Specification Document or “Business Requirement Document” or whatever your organization likes to call it.

So whatever user requirements we have, all are stored in Product Backlog, backlog.

Sprint Backlog, Sprint is defined time, teams work on to deliver certain items from product backlog. But before teams start working on those items (User Stories), those need to be properly defined.

Scrum – End -to-End Process

,