Skip to main content

DevOps - What and Why?

The very first question arises in the mind is "What is DevOps?"

Few will say it combined team of Developers and Operations. Some will say it is a person "DevOps Engineer" who works with multiple teams to get the things done in corrective manner.

Further questions comes in mind are:
  1. What is the corrective manner of doing things?
  2. How it is different from our "current" method of doing things?
  3. Do I need an extra set of tools for this?
  4. And, most important of them all, why should I use it?

Let me tell you what I've learn in my 3 days of DevOps training.

What is DevOps?
DevOps is not a team, or tool, DevOps is a culture. It is a culture for collaboration, Integration and Communication between different cross functional teams for Continuous Delivery. DevOps is not an additional team, but it is the existing team members who work together. It breaks the barrier between Infrastructure and Code at early stage.

DevOps also encourages Operations team to participate early in the Development Cycle so that products are designed to be easily deployable and maintainable.

*Image Source: Wikipedia

How can I implement DevOps culture in my project?
  • Automation Everywhere
  • No Manual Intervention
  • Use of Open Source (optional, but vary w.r.t. Application & Client)

It also ensures:
  • Collaborative Development
  • Continuous Testing
  • Continuous Release and Deployment
  • Continuous Customer Feedback and Optimization
  • Continuous Monitoring

How one can archive DevOps?
To get the maximum benefit from DevOps, one need to follow a certain path and need to implement few new process in their application development life cycle. Such as following:
  • Configuration Management
  • Continuous Integration
  • Automated Testing
  • Metrics
  • Collaboration
  • Making smart use of smart people


As soon as a change comes in to the version control tool, it will start testing the stability of the code & automated testing will start. In case of some failure, an alert will goes to the stakeholder, they will fix the issue and process will start again.

When all the test cases are successfully executed, automated deployment will get triggered and code will get deployed to production environment. Following this process with close the gap between the team located is different geographical location and there will be no time wastage.

Infrastructure monitoring and Analytics is also possible automatically.

Why DevOps?
OK, after understanding about DevOps culture, its objective, output, next question which comes to our mind is "Why should I adopt DevOps?"

In simple point after adopting DevOps culture you will get the followings:
  • Rapid Prototyping
  • Effective Support
  • Micro Services Architecture
  • API Support
  • Automation
  • Experimentation
  • Polyglot Enablement
  • Platform as a Services (PaaS)

Most of the things will be automated with DevOps (Testing, Deployment, Analytic, Monitoring etc.) you will get time to work on your Backlog and achieve more. You will be experimenting new things/tools. Dependencies of your applications can be identified at earlier stage and you don't have to waste time at the time of actual production deployment.


Achievements:
  • Code, Environment and configuration at one place
  • Automation of code release
  • Faster Release Cycle
  • Shorten and amplify all feedback loops
  • Quality - with feedback comes quality
  • Defects and performance issues fixed faster
  • Better Communication
  • More work getting done
  • Efficiency, Predictability, Reproducibility & Maintainability

Comments

  1. It's interesting that many of the bloggers to helped clarify a few things for me as well as giving.Most of ideas can be nice content.The people to give them a good shake to get your point and across the command.
    Devops Online Training

    ReplyDelete

Post a Comment

Popular posts from this blog

What is release, and what is a deployment?

T o understand the concepts and the technical implementation in many tools, you need to know how tool vendors define the difference between a release and a deployment. A  release  is a package or container containing a versioned set of artifacts specified in a release pipeline in your CI/CD process. It also includes a snapshot of all the information required to carry out all the tasks and activities in a release pipeline, such as: The stages or environments. The tasks for each one. The values of task parameters and variables. The release policies such as triggers, approvers, and release queuing options. On the other hand,  Deployment  is the action of running the tasks for one stage, which results in a tested and deployed application and other activities specified for that stage. Starting a release starts each deployment based on the settings and policies defined in the original release pipeline. There can be multiple deployments of each release, even for one stage. ...

PowerShell: Get Actual Error

I was having hard time to find the reason why I was not able to find a custom method in a .Net DLL. Find your Assembly: PS C:\vstsagent\A1\_work\r1\a\_DevOps_CI\Scripts > [appdomain]::currentdomain . getassemblies() | Where - Object FullName - Match "MyAssembly" GAC Version Location --- ------- -------- False v4 . 0.30319 C:\vstsagent\A1\_work\r1\a\_DevOps_CI\Scripts\Tools\MyAssembly . dll PS C:\vstsagent\A1\_work\r1\a\_DevOps_CI\Scripts & gt; $ a = [appdomain]::currentdomain . getassemblies() | Where - Object FullName - Match "MyAssembly" PS C:\vstsagent\A1\_work\r1\a\_DevOps_CI\Scripts & gt; $ a GAC Version Location --- ------- -------- False v4 . 0.30319 C:\vstsagent\A1\_work\r1\a\_DevOps_CI\Scripts\Tools\MyAssembly . dll When I was trying to get the Types in the assembly, I was getting the exception: PS C:\vstsagent\A1\_work\r1\a\_DevOps_CI\Scripts > ...

Considerations for deployment to stages

When you have a clear view of the different stages you'll deploy, you need to think about when you want to deploy to these stages.  Continuous Delivery is about deploying multiple times a day and can deploy on-demand. When we define our cadence, questions that we should ask ourselves are: Do we want to deploy our application? Do we want to deploy multiple times a day? Can we deploy to a stage? Is it used? A typical scenario we often see is continuous deployment during the development stage. Every new change ends up there once it's completed and builds. Deploying to the next phase doesn't always occur multiple times but only at night. When designing your release strategy, choose your triggers carefully and consider the required release cadence. Some things we need to take into consideration are: What is your target environment? Does one team use it, or do multiple teams use it? If a single team uses it, you can deploy it frequently. Otherwise, it would be best if you were a ...