ThinkPalm’s DevOps capabilities span all facets of Software Development Life Cycle including DevOps Assessment and Planning, Agile Tools and Practices, Continuous Integration and Delivery Pipelines, Multi-Cloud Support, Monitoring and Analytics, custom development of dashboards, tools, connectors and accelerators, Training and Consulting services and On-site and Oﬀshore Support.
Our expertise extends across a broad spectrum of tools in the DevOps landscape including Jenkins, CircleCI, Bamboo in Continuous Integration, Selenium, jMeter, TestComplete in Continuous Testing, Kibana, ElasticSearch, Splunk, Logstash in Continuous Monitoring, AZURE, AWS, Docker in Continuous Delivery, Sonarqube in Code review and Ansible, Chef and Puppet in Code Deployment. The scenarios emphasized below depict the foothold we have acquired in the DevOps revolution by delivering bespoke DevOps solutions, leveraging extensive tools and technologies.
In a typical scenario, developers perform a commit of code changes to various Feature Branches or the master/trunk. There would be multiple commits across various time zones into the main Git (Repository) server. At a predeﬁned time (once in 24 hours), a cron job picks up a predeﬁned branch to perform a build which would be subsequently queued for automated nightly test runs. Multiple, stable automated nightly runs lead to a “Release Candidate (RC)” being built. The Release Candidate is picked up by manual QA for regression runs.
As depicted in the ﬁgure below, the process contained gaps in terms of testing:
i. Multiple commits before a build led to diﬃculty in tracing back build failures to speciﬁc commits.
ii. Absence of integration testing before commits.
i. Multiple builds queued for testing, but just one build was tested per night.
ii. Not all branches and as a result not all commits could be tested due to manual changes in priorities.
i. Due to the cascading eﬀect of Gap 1 and Gap 2, builds reached manual QA late into the PDLC.
ii. Defects, sometimes release blockers, were reported during regression cycle, resulting in reduced time for development to ﬁx and re-test.
Lack of integration testing and lengthy test cycles led to build failures and defect detection very late into the Product Development Life Cycle, leading to expensive bug ﬁxes and delayed delivery.
In order to ﬁll the above gaps, the Continuous Integration process was introduced. The goal was to create a Jenkins test suite, integrated into the client’s Git server, to initiate a test suite run for each commit. Post implementation, CI resulted in the following changes:
1. Developers perform a commit of their code changes into the Git server for various branches.
2. Post each commit, webhook to Bitbucket triggers build pipeline on Jenkins for the speciﬁc branch.
3. Pre-build tests like Doxygen, code review tests and code analysis tests are run.
4. Full Build is performed to build a binary image on the local Git client.
5. Connect to the test server using SSH to trigger functionality tests.
6. The binary image is deployed on the DUT.
7. Automated tests are executed on the DUT.
8. Results are captured and processed by Jenkins.
9. Test reports are formatted and mailed automatically to the committer along with commit information.
Other highlights include:
• Completely virtual test-bed in the test set-up, implemented using Virtual Box, with no cabling between devices.
• Automated branch speciﬁc build process after every developer commit using a webhook in Bitbucket for Jenkins.
• Multi-branch support.
• Queuing of builds if a commit occurs while a build is being tested.
• Capability to submit private builds for testing on the CI set-up.
Continuous Integration of development, pre-build testing, build process, deployment of the build on the DUT and automated Sanity & Integration Testing were achieved.
This led to stable, sanity tested builds being submitted to QA for regressions. Early detection of blocker issues lead to eﬃcient tackling and faster deployment of software to the client.
An automated system for facilitating faster validation of code, early detection of defects and automated deployment of builds to test beds was lacking in the client environment. The test beds employed physical machines, making the setting up of multiple test beds and their conﬁguration expensive. After each deployment, test scripts were executed by Engineers and notiﬁcations on each test case status had to be sent manually.
ThinkPalm automated branch speciﬁc build process by triggering the build and deployment pipelines after each developer commit. Support was extended to both partial and full builds. All machines in the test beds were conﬁgured as virtual machines and multiple test beds were made capable of running on one physical test server. Auto deployments were implemented where new build artifacts get pushed to the test beds after each auto build. After each deployment, automated execution of test scripts for the concerned development branches was realized, along with the receipt of detailed status information on each test case.
End-to-end automation improved the eﬃciency of all build, deployment and test cycles signiﬁcantly. Use of virtual test beds saved costs on additional hardware for setting up test beds. Quick TAT for testing builds for each development branch helped in early detection of defects. Parallel builds on diﬀerent branches reduced the wait time for deployment, improving the time to market. Auto conﬁguration and updates to the testing server considerably reduced the manual intervention in test deployments.
Identiﬁcation of feature changes from source control history was implausible due to lack of validation of each commit to the source control server. The laborious tasks of triggering builds, preparation and management of test releases, deployment of new test releases to testing servers and their conﬁguration were performed manually by Test Leads and Test Engineers, resulting in wide gaps between production releases.
The diﬃculties were overcome by implementing Continuous Integration using Jenkins, encompassing automated builds, test release automation and test deployment automation. A speciﬁc custom test release management tool was introduced and ports were added for multiple development branches.
Automation of builds, test releases and deployments brought about higher frequency in production deployments. Implementation of automated control measures for code commits realized the tracking of feature changes together with clear visibility of feature developments. Daily automated builds and deployment to staging server resulted in early detection of defects and early checks/reviews on new features. A custom test release management tool was developed. Facility for remote triggering of builds and automation of test releases and deployments helped Development Leads and Test Engineers save considerable time in conﬁguring and deploying custom builds.
Download the case study now! ThinkPalm’s BreakThrough DevOps Capabilities
Contact us and we'll have one of our experts reach out to you and discuss how we can lead your project to success.