DevOps CICD

DevOps – this term is rapidly spreading throughout the community. While this is new and many organizations are still discussing adopting, people have lots of confusions and many times contradictory impressions defining it and how it works. When it comes to testing and automation in DevOps, it creates lots of confusion again. In this post, we are going to discuss an overview of DevOps and will try to clarify some of the confusion. Hope you will find this useful.

What is DevOps?

Let’s start with understanding DevOps first, different people define it differently. If you are into DevOps or reading through, trying to understand or implement, you might have heard many different versions of its definition.

Let’s understand this in a very simple way —

A developer writes code for many different tasks like – Code for New Applications or products, Bug fixes, security updates etc. When this comes to deploying in the actual environment (Production environment) where users can use it, a developer needs to wait for days or weeks. The reason would the bandwidth for the Operations team to finish up there a huge pile of work before they take up new. This delay causes a delay in products available in the market also on the other hand it becomes difficult for developers to manage the multiple versions of code, one that is pending to push to production and the other on which he has to work on next. Moreover when the code gets deployed into the Production environment, occasionally unforeseen errors occur. This happens because developer writes code for their development environment which is not similar to the production environment. This ultimately increases work for the operations team to manage the environment and make sure systems are up and running. The operations team has to do lots of massaging on every new code that comes to production and continuously diagnose to ensure a stable environment. Any issue that occurs due to code, leads to many different issues in the production environment and delay in the availability of products in the market.
To overcome this major issue in Software Development Life Cycle (SDLC), the Developer and Operation must work together and share responsibilities. It’s about changing mindset and culture on how Development and Operations work.

So, DevOps is a phrase in SDLC, mean to Change and Improve the working relationship between Development and Operations Teams thereby improving collaboration and productivity by automating infrastructure, workflows, Continuous testing and Continuously measuring application performance.

See also  CI/CD for Automation Testers

 

How does DevOps Works?

DevOps is about changing the mindset, culture, approaches and tools that we use. It’s required to analyze everything being done manually and decide to continue it manually, eliminate or automate it.

Developers, Testers and Operations work together and identify and rectify the pain points beforehand. Establish a better collaboration, benefit into a better product and on time. There will be an identical environment for development and production with the same configuration. DevOps teams write configuration management code, which automates infrastructures and they will have the ability to build dozens of servers instantaneously

Success Criteria for any team depends on the right set tool-set. a DevOps oriented team requires the below tools to achieve the below

  • A development approach to involve and collaborate Development, Testing and Operations teams. Such as Test Driven Development (TDD)/ Behavior Driven Development (BDD). We will go through these approaches in detail in later posts.
  • Continuously build and test code with tools like Jenkins, TeamCity 
  • Tool for Source Control such as GitHub, Team Foundation Server etc. to track and manage code and Documents
  • Configuration Management Tools like Chef, Puppet etc for easy code deployments
  • Tools to measure the continuous performance of the application on servers

 

Benefits of DevOps

Technical benefits:

  • Continuous Product delivery
  • Less complex problems to fix
  • Faster resolution of problems

Business benefits:

  • Faster time to market
  • More stable operating environments
  • More focus on adding values to the product

Test Automation in DevOps

With all of the above, we understand that Automation is the key for a team that is DevOps oriented. The goal for a DevOps oriented automation team should be to “Automate Everything —  Continuous Code Testing easily and quickly build of Infrastructure.”

Test Automation in DevOps includes Continuous Integration and Continuous testing. Tests that are automated should be tested continuously for each build and all the tools should work integrated for a greater outcome. There is a need for faster automation development and a faster turnaround time for any maintenance that is required for the scripts. with there are automation tools like Selenium, Cucumber, LeanFT etc are being preferred over other traditional tools. The automation code is tightly integrated with the developer codes and it can be utilized for unit testing to regression testing as and when code is ready for deployment.

In our future posts, you will see more about these tools, approaches that are widely being used currently. we are going to deep dive into some of the tools. Stay in touch.

See also  It's important to understand BDD!

If you have any questions or want to share your thoughts about DevOps, please do so with your comments below.

 

12 COMMENTS

  1. Hi Saket,
    In Agile based application automation testing, we create automated test scripts for specific sprints. The integrated testing planned for the build with all the sprints combined along with few new functionalities integrated. What is the best approach to be followed for an integrated testing in such scenario and what could be the challenging portion which we should focus on.

    • Hi Malini,
      Ideally we should execute the whole set of regression/integrated automated suite along with the new test automated for a particular sprint. but in case where your automated execution will take longer that the execution window, below two approaches can be adopted

      1. Risk Based Executions – Identify a subset of functionalities which are a must to test for any changes in functionality. Execute the set of features accordingly.

      2. Dependent functionality/features Execution – as we progress with automation or manual execution for sprint, its a good practice to maintain a dependency track of features ( kind of traceability) and execute those dependent functionalities only for upcoming sprints.
      e.g in a particular sprint functionality E has gone through some changes or newly added. Functionality E is dependent on A and D from A B C D functionalities. Execute features/test cases only for A and D along with E

      hope this helps.

  2. […] LeanFT is a solution by HPE built for continuous integration and testing. It’s a fully integrated in standard development IDEs: Visual Studio, Eclipse, and IntelliJ. It enables the development of test scripts based on standard unit testing frameworks, such as NUnit, JUnit, and TestNG. With various features and capabilities, it’s a great tool for efficient automation and for collaboration with Agile and DevOps teams. […]

LEAVE A REPLY

Please enter your comment!
Please enter your name here

This site uses Akismet to reduce spam. Learn how your comment data is processed.