Automating manual work, for example, deploying your application or running tests, can be an challenging task. Most teams concur that automation is significant. In any case, not realising where to begin with this 'tremendous and significant thing', they continue pushing it into what's to come. In this post we offer a practical approach how we started with automation.
Implementing a good DevOps process will benefit any organisation to a great extent. This includes planning, developing, integration and automation. There are a few product areas that can immediately benefit from some integration and automation tasks that will reduce the manual work involved, increase the responsiveness of support team and also optimise the resources used. A typical DevOps implementation will integrate and automate the different process with tools appropriate to the customer. let’s see how we identified and assessed the roadmap of DevOps
Manual processes in a development life cycle, There are many manual steps in such a process. i. Checking out code to build server ii. compiling and doing the build iii. Deploying the application to test server iv. Testing by the QA team (manual part, if not fully automated) v. Deployment on test server vi. Deployment on staging server vii. Deploying the application to production server viii. Monitoring of the test, staging, production servers
To overcome this manual process, we started assessments in and transformation process
Assessment | Implementation | Monitoring and maintenance |
During this stage we surveyed the present condition of the association, its abilities, procedures, and innovations as for improvement and tasks. We concentrated on recognising existing difficulties and gaps, and distinguished open doors for automation to make standardisation. Subsequently, we spread out the DevOps guide for future stages by distinguishing every one of the tools, advancements, and systems required for automation and for executing different procedures. | We started to turn out procedure upgrades and automated procedures that have been recognised in the assessment phase. Both development and operations teams work in collaboration using newly defined processes and best practices such as agile delivery model (to deliver in iterations), continuous integration, and more. Toward the finish of this stage, we set up a comprehensive DevOps dashboard to monitor various activities and overall condition of the project | This is a progressing stage wherein we routinely screen the characterised DevOps processes utilising continuous improvement plans and administration models. |
Prerequisite factor of DevOps
There are a few prerequisite factors used for DevOps Implementation:
Code repository with version control
Continuous Integration (CI)
Automated Build
Automated Release through Continuous Delivery or Continuous Deployment (CD)
Determining the right tools
Along these lines, how would we set up something that makes it feasible for us to move at that pace and satisfy our goals. For us, the huge thing that we needed to do was take a look at our tools. What we did was placed in a tool chain, beneath you'll see a case of our DevOps that we use to build up our product.
At the underlying stage, we arrive at the client through different showcasing procedures, marketing strategies, after getting customers requirement, we do an undertaking plan and begin to deal with it. We at that point use Confluence. all the new thought that comes in, documentations of tasks, DoD's, Manifesto we put it out in Confluence, and we get a great deal of joint effort from our around the groups who are communicating with our customers requirement. After requirement gathering Finally, we use JIRA for project management, for task management, for agile boards, etc. so that we can keep track of everything we are doing. The next phase happens as we start working on development, application understanding, to validate our code, debug our code, edit, and manage our code, and test the code and application etc.
Next, we have to make sure that we have some version control, so, we use Bit-bucket version control systems. We use Bit-bucket version control system for our distributed code. We believe that the source code should be managed on the platform from where it is going to be built and executed, We use Jenkins for our continuous integration into Bit-bucket to identify when code changes are made. Once those code changes are made, it automatically initiates automated testing; as well as builds.
Then the results from our testing go into Sonar where we can use it to identify code quality, identify how the changes are made to our products, and how our code is impacting the quality of what we are delivering. For test automation, we use TestNG, Selenium. So we’re monitoring the continuous performance and continuous viability of our code changes. And then, finally, we get to where we have to deploy. Again, we use custom scripts to do deployments across different platforms, and that allows us to move and confidently move code changes from development to QA to production.
Then, once we’re in production, we have to monitor if there’s faults, errors, or any performance issues. We continuous monitor performance, and we have an integration back into JIRA. Within the environment, if an issue is found, JIRA issues can be opened and sent back to developers so that they can keep a continuous integration in the true spirit of being fully DevOps enabled.
Project life cycle phase | Purpose | Tools that we used |
Development | Source control management | Bit-bucket |
| Code analysis | SonarQube |
| Implementation of continuous integration | Jenkins |
Testing | Unit, performance, web, and services testing | Junit, TestNG, JMeter, Selenium |
Release | Build and releases | Maven, Gradle, MSBuild |
Deployment | Automation of deployment | Custom deployment scripts, file copy scripts, deployment plugins for Jenkins / CI tools |
Monitoring and maintenance | Continuously monitor the application and server environment post application deployment | Web analytics scripts, application health- check monitoring tools, server monitoring tools, server logs, deployment logs |
How did we really achieve this?
Code Commit and Version Control
Continuous Integration (CI) is a development practice that integrates code created by multiple developers through an automated framework. We used Jenkins as the CI/CD tool, and adopted the following process:
If the build is successful, then manual merge-request to master branch is generated.
The merge-request triggers a new build, which builds the production release and merges with the master branch.
Automated tests are executed on the production release.
If the automated tests are unsuccessful, an automatic failure notification is generated.
If the automated tests succeeds, Jenkins starts to compile code to create an artefacts of a merge-request and automatic build passed notification is generated. (notification contains the details of released artefacts, unit tests reports and other logs of builds).
The Wrap The level of automation that one decides to implement as a major aspect of DevOps, will be largely determined by the nature of the development environment, just as the production and/or live environments. The privilege tooling and work process will go far in guaranteeing that the most recent code is consistently in a production-ready, deployable mode.
Category | Before implementation | After implementation |
Infrastructure | Nonstandard, disjointed, and fragmented | Organised and standardised technology stack |
Teams | Each team spends considerable, manual effort to execute, develop, test, and release management activities. | Increased collaboration across all teams using automated processes and consistent goals. This leads to increased team productivity and lowered operations cost. |
Delivery model | Longer release cycles Delayed Deployments | Incremental releases Rapid Delivery |
Development and testing processes | Traditional Manual Costly and error prone | Iterative & incremental releases Automated testing and continuous validation |
Effectiveness of end user feedback and change requests | Inability to overcome challenges in handling change requests and enhancements leads to longer change implementation period | Higher effectiveness of change requests, feedback, and enhancements due to agile delivery |