The need for mobile applications has increased manyfold in this technological era. They have changed the way we interact with our surroundings. Therefore, developers are seeking more convenient ways to create mobile applications. Which not only guarantees the highest quality but also ensures less time to market.
DevOps and Agile are two approaches that have emerged as critical players in this space. These technologies help a developer create more professional, reliable, and efficient mobile applications that aim to enhance the users’ overall experience.
DevOps is a methodology that combines operations and development. To streamline and automate the entire app development process. While Agile is a methodology that mainly emphasizes development, teamwork, and continuous feedback.
Whether you are a professional developer with years of experience or just starting your career as a mobile app developer, adopting DevOps and the Agile approach will surely help you to develop the best mobile application that your users will love. Let’s find out how the developers can leverage these platforms to benefit their projects.
Delivering a high qualified software is not a Unique Selling Point anymore but a prerequisite for better customer experience. In the present era, the customer is very educated about the choice and comparison between the best services or products. Along with quality goes the promptness in service delivery. In terms of Quality Assurance, both can be achieved by implementing Agile and DevOps best practices. The developers have achieved a lot in terms of solving quality issues and delivery with the help of automation. To ensure constant success in this maneuvre, the firm has to ensure that the metrics to be tracked are chosen rightly in order to maintain the quality throughout the development process.
The delivery of mobile apps is done differently than other ordinary apps. Although the elements of Devops – agility, Continuous integration and continuous enhancement are followed in both the cases but specifically in case of mobile apps, there has to be a unique strategy and tools.
What are the mobile application delivery challenges?
Mobile apps are built for smaller screens, need of touch output are completely different than that of web apps which need mouse or keyboard. Apart from these, it faces other challenges like:
Fast Delivery
Mobile app users are used to fast service of apps, automated updates and quick response time. So to maintain the competitiveness, the mobile app industry has to focus on methods and tools that leverage quickness and quality of the output delivered. The faster the performance of the apps and updates, higher will be its chances to overpass the competitors.
Design and build of Mobile Apps
Mobile apps are built on a different understructure. The entire build and design exercises have to be executed and tweaked according to the screen size and device architecture. Also, based on the advantages of mobile device, the apps should utilize the features like camera, GPS, Bluetooth, voice/video calling to give an edge to the app’s friendliness and captivating ability. If the mobile app is poorly fabricated, it will quickly drive away the users.
Competition in the market
As per the latest statistics, there are about 2.8 million Android apps and 2.2 million apps available on Apple store and thousands more are released each month. The app with the unique features will only be chosen and the competition increases as the mobile device market advances.
App Store dependability
Who knew that app store would be a challenge? Yes, most of the times the apps cannot be deployed directly to the device, it has to go through the app store. This acts as an additional step in the process which delays the app deployment on the user’s device. It also restricts the developers to push direct updates or critical bug fixes in the app. So instead of being a ‘continuous delivery’, it becomes ‘awaited delivery’.
Above are some of the most common challenges that are faced in mobile software delivery but how to meet these challenges?
The Devops team can follow a more analytical approach to the software delivery with a concrete set of Devops principles.
Most organizations tend to monitor their built apps only in the production stage after releasing it to the end users. This is the biggest mistake they can do. The DevOps team will have to reconsider this practice and work on a different approach by monitoring the critical measures at pre-production stage. Continuous monitoring and making early stage improvements would really matter in the overall app success.
2. Achieve quality at good Speed:
To achieve ultimate success, the DevOps team has to focus on quality with speed and also consider the cost it would incur. To accomplish this powerful goal, the team has to adopt DevOps and agile practices alongside. According to Forrester analytics reports, the firms who have adopted this approach has seen a rise in the benefits like technical and functional quality, and high delivery frequency. By emphasizing on building the expertise of the resources, implementing continuous testing, involving testers as a part of integrated testing phase, automating end to end functional testing and by implementing shift-left testing at all levels of development cycle, the firms give the software testing a new face leading to business transformation.
3. Multiple Channel Visibility:
Mobile apps have to be built for serving different platforms. Along with the web version of the app, the DevOps team has to deliver a mobile version in most scenarios. In order to attain this understanding, developers need to analyze what is the journey of the users when they decide to switch from web to mobile apps and one device to another. This is a critical data that would be the deciding factor in developing the app for different channels.
4. Automating to the maximum:
As per the Forrester study conducted on the success of advanced Devops+Agile firms, the firms have automated most of the testing processes by 50 percent in order to reap the benefits of successful Mobile Devops. The result is faster and quality software delivery by a continuous testing implementation.
5. Constant feedback:
This is the most discussed and the most important point. The developers must identify the issues the application is facing in all the stages of delivery in order to take corrective actions on time. DevOps team has to be vigilant and responsive to all the issues that arise at every step. In this fast-paced Mobile app development market, this is a must have key point.
Benefits of Agile and DevOps Integration
Enhanced client satisfaction and reduced time to market.
Improved delivery speed and efficiency.
Enhanced team cooperation and communication.
Increased focus on innovation and continuous development.
Ability to respond quickly to changing company needs.
Implementing Mobile DevOps: A Three-Step Guide
Organize Continuous Delivery and Integration
Integrate and track all code, scripts, documents, and configurations.
Ensure build consistency and version control for scripts.
Utilize virtual instances to test the app ecosystem more quickly and affordably.
Add a third-party SDK integration for ongoing app monitoring.
Concentrate on Delivery and Quality
Check code integrity at each level of development.
Monitor the app for any flaws and improve functionality.
Conclusion:
Mobile DevOps is a distinct software practice which is built on top of the traditional DevOps mechanism. It demands an extra attention to all the processes in order to produce a fast and quality software delivery, extraordinary application design and commendable user experience to facilitate success in the mobile application market. It carries a bigger picture by focusing more on the ‘business DevOps’ rather than just ‘DevOps’. To attain maximum DevOps Feat, the DevOps team has to be a step ahead in adopting new analytical approaches at every step of development and delivery. It has to be instinctive and provide continuous visibility to the delivery pipeline to gauge the ultimate app performance in the User market.
Choose pCloudy for your Mobile DevOps and Agile needs. Our cloud-based testing infrastructure offers comprehensive solutions that can help you to expand your target audience, enhance testing efficiency, and ensure the quality of your apps. With over 5000+ real devices and browser combinations, our platform provides Continuous Testing, DevOps, Advanced Automation, AI-based Visual testing, Robotic Process Automation, Real-time Test Analytics, and more. We also offer 24×7 support to help you address any concerns you might have. Don’t hesitate to contact us to discuss your Mobile DevOps and Agile needs today.
In today’s organizational environment, ‘DevOps’ is the most used buzzword and has become a part of its agile software culture. Organization’s DevOps success is not a single goal approach; it requires deeper involvement for making a switch to DevOps. Broadly, it requires adoption of new DevOps automation tools, contemporary processes and cultural shift, especially in case of Mobile DevOps tools selection. A business has to be equipped with ever-evolving principles and DevOps automation tools in order to embrace these steps to successful DevOps test automation.
There are multiple Mobile DevOps Tools with different strengths contributing to a reliable Mobile DevOps process. Today, the businesses and the development teams are investing in intelligent systems that are capable of monitoring the production and development metrics in real-time. This acts as great deal for the development firms unless it covers all important aspects of the process allowing perfect optimization of the resources based on the reports.
The journey from planning, development, deployment and beyond, generally called ‘shift left’ process which is a part of continuous testing. In this approach, the testing is mostly focused on earlier stage of production life cycle aiming at delivering applications faster and with much lesser time and money. When it comes to mobile apps testing, the shift left approach works well because the application has to be tested well in order to perform well in the real-environment. In case of Mobile DevOps, using production environment to test the mobile application on real physical devices would help highlight and fix issues in the earlier phases of SDLC, reducing costs and time.
Gone are the days when testing was only executed as a final step of the processes where as nowadays, it has to be performed after every build, at every stage of the process. It is with the help of multi-step testing and maximum data capture after each test cycle, that the status of development and testing hasn’t been compromised enabling early bug-fixing and building more strong applications especially when this process is simplified with the help of DevOps automation tools. DevOps and Automation go hand in hand. Despite many challenges, it carries a much strategic role to bring the whole business making faster and better applications. A developer has to have a combination of agile development methods along with Mobile DevOps to win in mobile application; this can be achieved with the help of right DevOps automated testing tools.
Below are the 7 most common Process Steps with Mobile DevOps Tools:
CODE
Anything related to real development is related to continuous integration whether it is code development or code reviews. The way developers work today by collaborating; integrating all the things together is all a gift of the agile approach which is responsible for making continuous integration popular. With the adoption of continuous integration early stage issues are detected which ultimately reveals any integration glitches, faults in the code commits, etc. It generates a lot of data required for making right choices to be made by the developer as it showcases a lot of data about the mobile application that the developers can use to make the code better. This thus ultimately helps in estimating the scheduling and time consumption more accurately.
BUILD
Build is nothing but application components that are collected repeatedly and compiles for the purpose of testing to produce a reliable final software product. This is not a one-time job, instead it is a developer’s everyday task of creating various builds of applications. In Mobile DevOps scenario, in order to notify the status of the build, the developers use various version controls and source code management techniques. Software Engineers normally follow branching techniques in case of Mobile DevOps like no branching, release branching, maintenance branching and branching for features.
TEST
Testing is something that acts as a backbone of building a quality product. It is the QA team that is responsible of maintaining the sanity of the software, detecting errors early and quick bug fixing. Testing is the most integral aspect of SDLC. Considering the Continuous integration principles, automation testing needs to be automated in order to enjoy the seamless results i.e rich and flawless application. Testing in Mobile DevOps for a production environment should always be performed on real mobile devices and not on Simulators.
PACKAGE
Packaging in Mobile DevOps is already known. It is all about tools for package repositories and storage mechanisms for the binaries created during the software build. Binaries like scripts, configuration files and other files facilitate deployments; these are contained in the asset repositories. Continuous deployment eases the application testing and production with the help of automation, flawlessly. Packaging enables the releases of new versions and features of applications to the end-users.
RELEASE
In Mobile DevOps process, there are myriad of tools that are used in aiding in the process of CI/CD and continuous release. As a part of this, there are application release tools as well that help in packaging and deployment of an application right from the development to production, to be available to the final users using automation. Release management is a critical expertise which involves planning of every release and deployment by easy collaboration with the stakeholders. This is accomplished with the usage of release management tools that help stakeholders to plan and execute and trace the releases from a single platform.
CONFIGURE
Configuration is a second name to Infrastructure as a Service. Configuration tools enhance the cost-effectiveness and create applications with better flexibility and performance. The aim of this process step is to remove any unwanted manual configuration. In DevOps , the focus is on automation and collaboration, so configuration being a part of the ecosystem is also automated across various development flows.
MONITOR
Without valid data, no corrections and improvements can happen. Thus, monitoring becomes a very important aspect of the Mobile DevOps ensuring that the organizations get the right metrics about the processes, stage wise results and final outcome. Continuous monitoring allows stakeholders, developers, testers and other people involved, the access to right information for evaluation and decision making. This step is guide to all teams involved and has an impact on all the other steps. Thus making it a critical process step with Mobile DevOps tools.
Traditionally, the Process Steps involved planning, developing, testing and deploying but this is not it, there are many more aspects to it that are the key deciders in selecting the tools and how they fit together to enable tool flow in SDLC. DevOps test automation helps in achieving integrated development and delivery using the right combination of DevOps automated testing tools.
We all understand the importance of software testing and how it transforms the goodwill of the business by enabling delivery of quality product to its clients in shorter delivery cycles. It becomes challenging to run the test cases manually by evaluating the quality of each line of code at every step of the continuous Delivery process. This is where Continuous testing in DevOps comes into picture.
Continuous testing in DevOps Pipeline
In traditional ways of testing the software used to pass through different development and QA phases which took more time until the final delivery of the product. According to a research by Gartner, Continuous testing in DevOps is aimed at providing early and quick detection of signs of risks related to the product release. DevOps Continuous Testing is an inevitable activity of the delivery process rather than just a mere stage in the delivery process. The main purpose is to inculcate quality into the CI/CD pipeline by utilizing the key benefits of continuous testing in DevOps.
DevOps Continuous testing is a critical aspect responsible for seamless Continuous Delivery. It involves the usage of agile development methods and processes into the QA process further providing a productive testing process.
Here are a few points to understand the benefits of Continuous testing in DevOps at the deeper levels:
a. Provides Sustained Risk Analysis:
There has never been any code build that is error free and in a ready-to-release form. Even if the final release candidate has come without any glitches, passes all the tests, it has to be ‘prepared well’ for the final release and approved by the business leaders. Continuous Testing evaluates the code at a deeper level to estimate all the possible risks connected to it so that a corrective action could be taken at the right time without breaking the ‘continuous delivery’ chain.
b. Cuts down the feedback cycle:
The key benefit of continuous testing is that it evaluates the code layer by layer at each stage of delivery pipeline, allowing testers to understand the source of the problem. The actionable insights helps the QA team to act on time and avoid longer queues
c. Broader Test Coverage:
A broad range of tests can be applied throughout the testing process with the help of continuous testing tools for DevOps such as Selenium, etc. It covers both functional and non-functional testing types to increase test coverage by emulating testing like cross-browser testing, API testing, regression testing, integrated testing, unit testing and non-functional testing like security, reliability, scalability, usability and many more.
d. Delivering High Quality Product:
‘Test-early-test-often’ is the key mantra of continuous testing which is self explicable. In order to ensure delivery of high-quality product to the end user, there needs to be a process to continuously monitor the progress along the entire delivery pipeline. Achieving high product quality is the result of continuous testing that strives to finding and addressing risks effectively and by gaining feedback at the early phases of software development lifecycle.
e. Faster Software Delivery:
The whole point of introducing Continuous Testing in DevOps is to speed up the product delivery cycle. Following a multi-point testing at different stages allows the QA team to detect the glitches early and take quick corrective actions so that the final delivery is not impacted.
f. Easy Integration with the DevOps Process:
Continuous testing seamlessly integrated with the DevOps process right from the early stages of the development process rather than functioning just before the release. Continuous integration into the software pipeline enables quick fixes so that the development process can be aligned with the business requirements on time.
Tools for continuous testing in DevOps
For a seamless experience in the entire CI CD process, Continuous testing has to be supported by the best tools for continuous testing in DevOps. For performing smooth Continuous Testing, the Automation Framework has to be integrated with the CI tool, version control and various automated continuous testing DevOps tools to execute different types of testing at various stages of the process. For example, :
Using Selenium for performing functional testing
Load runner for performing load testing at its best,
Secure code analysis using Fortify and static code analysis using Sonar, etc.
Apart from these there are many other trusted DevOps Continuous testing tools available in the market for an efficient continuous testing, like JIRA, Jenkins, Bamboo, Docker, Appium, SoapUI, PagerDuty, CodeCluster etc. The concern is that not all the tools support comprehensive automation solution. Some organizations prefer to create self-made automation frameworks depending upon the version control used to enable complete automation of the CD pipeline.
Since Continuous testing is the most critical aspect to be covered by the business in order to achieve quality product release, it has to be backed by the choice of right, suitable tools and frameworks to achieve speedy and quality delivery.
Challenges in DevOps Continuous Testing and how to overcome them
Even after understanding the advantages of adopting continuous testing in the DevOps process, many organizations face the challenges of successful implementation of it. Establishment of an efficient automation framework is a daunting deal as it involves a huge investment, expertise and effort. Moreover, the organizations are not equipped with the scalable infrastructure to run tests continuously. Also, without a strong coordination among the product, development and testing team, this seems even tougher. Although there are challenges in successful adoption of Continuous testing, with a little sensibility one can overcome it. Here are a few of the key points to comply in order to overcome the challenges :
By proper team engagement, the cultural and communication barriers can be dealt with enabling the SDLC team to have better coordination, collaboration and understanding of the scenarios.
Reducing unnecessary and extensive testing plans, the focus should be on keeping it simple and logical. Instead, the energy could be diverted to more important test objects in order to create much better measurable results.
Automation would ease the successful implementation of continuous testing in DevOps. Well, complete automation isn’t achievable but more the process automation, easier it becomes to carry on the continuous testing.
Carry out testing at all stages of production and QA environment would continuously providing feedback to developers to improvise on the product quality.
Last but not the least, implementing artificial intelligence and other intelligence programs for problem solving and to think beyond automation at every stage of delivery would boost up the SDLC.
By now we all know how significant continuous testing in DevOps for any business. It essentially brings together all the stages of designing, developing and deploying the software. Merely providing a software product does not help but providing best products faster than the competitors would be the key differentiator of your business. If practiced earnestly, it provides consistent insights about the software development to ensure speedy delivery.
DevOps helps enterprises to build software at a fast pace and with minimal issues. The time to market is accelerated and the bugs are fixed faster in continuous deployment with the help of automated tools. AI is much in line with DevOps as the main focus is on automating the process and with AI the system can identify patterns, anticipate issues and provide solutions. The proactive approach improves the overall efficiency of the software development life cycle. So let’s have a look at how AI is transforming DevOps.
Feedback Loop and Correlate Data
The main role of DevOps is to take continuous feedback at every stage of the process. often people use performance monitoring tools to get feedback on running applications. These tools gather much information in the form of log files, data sheets, performance matrix, and other types. The monitoring tools use machine learning to identify the issues early and make suggestions. The DevOps teams use these suggestions to make the necessary improvements to the application. Many times teams use two or more tools to monitor the health of the app and the data from all the platforms can be correlated by the help of machine learning to get a more deep understanding of the app functioning.
Software Testing
AI is changing DevOps for good by enhancing the software development process and making testing more efficient. Whether it is regression testing, user acceptance testing or functional testing, these all produce a large amount of data. AI can figure out patterns in the data collected in the form of results and identify poor coding practices which produce a lot of errors. This information can be used by the DevOps teams to increase their efficiency.
Anomaly Detection
DevSecOps is one of the essential aspects of software development as security is the key to any successful software implementation. Distribution denial of service attacks are increasing and the business needs to prepare themselves to protect their security systems from hackers. DevSecOps can be augmented using artificial intelligence to enhance security by central logging architecture to record threats and running machine learning based anomaly detection. This will help businesses proactively attenuate the attack from hackers and DDOS.
Alerts
DevOps approach might create scenarios where the team receive an overwhelming amount of alerts without any priority tag. This will create ruckus in the teams as it will be very difficult to handle all the alerts in the continuous development environment. AI can help in this scenario by tagging the alerts and prioritizing them so that the urgent ones can be worked upon immediately.
Root Cause Analysis
To fix an issue permanently, a root cause analysis is necessary. Although it might take time to do it compared to fixing the issue with a patch which will provide the instant solution. In order to find the root cause of an issue, the developers will have to spend time which will delay the release of the product. AI can speed up the process by finding patterns in the data collected and implement to fix the root cause.
The collected data can be used by implementing AI to find a pattern and speeding up the development process. The organized data is more useful and makes prediction possible. The best practice is to use machine learning to automate the tasks which are time-consuming which will ensure the smooth and effective functioning of the DevOps teams.
Here I present the 4th blog in the DevOps series showcasing our learning while #scalingup. Read our previous blog to know about the lessons we learnt from our scrum.
Most DevOps patterns are exhaustive and would need some strong commitments, in terms of both time and effort which is why many a times people hesitate to introduce DevOps to their teams. Because there usually is a lot of change required in your way of working and the way your workflow flows when you try to retrofit a DevOps into your setup. More so if you did so without thinking hard about the consequences. So how did we create a continuous system of delivery? How did we make a system that is robust yet flexible enough to incorporate the needed changes?
DevOps has a unique challenge. It is difficult to retrofit DevOps into a running system and doing that is not going to directly bring revenue. So in a running startup setup we simply cannot imagine stopping everything, spend time exclusively on this and then go back to our other tasks. But it does not mean that we can’t’ have a functional DevOps, it only means we have to go from MVP (minimum viable product) to MVP on this, and the earlier MVPs might seem pretty embarrassing but it is useful to prove the concept first and then go on and build the concept. Else you might end up with a sophisticated solution that is working but may or may not be what you need.
I have already talked about our thought process where we are against blindly reinventing the wheel or retrofitting someone else’s wheel onto our vehicle. The same goes for DevOps, barring obvious things, we never did any upfront development for DevOps or DevOps processes, rather we went step by step automating bits that we could and bureaucratized bits that we couldn’t. And then went back and discarded the failed MVP, and formalized the ones that have passed. And as always kept doing it. Because above all DevOps is a result of the Agile attitude more than anything else. If you are not thinking agile when you build your DevOps, then you will end up with a random bunch of automated tools, and not a living, breathing system of delivery.
So, here are our bunch of tactics that we used at different times during our evolution to achieve a successful clockwork.
Forms
The most bureaucratic of them all. Forms are the ultimate icon of a bureaucracy. Whenever you want any service done from any bureaucracy, you have to fill a form. And it definitely looks uncool. However there is a reason why it is still going strong across the world both offline and online. The primary benefit of a form is that you get all the data you need in the correct format and it is easy to find out if any required data is missing. This helps because data being missing can be addressed at the very beginning and not later on. Where we use forms is when one group of people need a service done by another group whose work is totally different from the first. For example, when developers want the deployment team to deploy something somewhere (any of our test envs or staging or production) now a developer could do it. But the deployment team owns the passwords and access to the staging and production setups which devs do not have and they also own the best practices which the dev team may not know. One of the problems they faced was that each developer had a different idea of how to push their artifacts to production. For devs of one domain, just copying code was enough, others needed binaries to be changed, still others wanted binaries and configurations to be changed. Some needed process restarts and others did not. Some needed server restarts while others did not. For some devs running an update script was enough while for others some other thing also had to be done. It was very difficult to keep track of these. One solution would be to have the deployment automated. And that is where we eventually reached. But that was not a one day job, and till that was done, we could not have stopped deployments.
So we needed to make sure that the deployment team had the right info when the request was made and not then the team had done half the deployment. We experimented with emails, but most devs wrote what they thought was relevant and not what really was relevant. So we asked developers to mention all that was needed. But that also was not too clear a requirement. And many still missed the requirements. So we created a form. The biggest advantage, is that the developer cannot now accidentally miss any important info. It is difficult to miss info when the form explicitly asks for info. So now developers fill all the info even the ones they think are obvious or irrelevant. And the deployment team was now empowered to act like a bureaucracy and reject a form for data not filled. This worked like magic, our deployments became less buggy and there was far less cases where dev and deployment teams were arguing about what they meant when they said something. The direct result of adding deployment forms was that our deployments were now far less broken.
Checklists
It is the checklists that eventually gave us the idea that forms can also work. Checklists are the zero brainer tool of choice for a lot of people. And it has been so for almost a century now. Perhaps more. However the power of checklists are often underestimated or ignored. You need to read The Checklist Manifesto – by Atul Gawande, to understand how important and valuable checklists are and how crazy it is to ignore them. There was a huge list of things that we were many times not doing right or missing small or obvious steps. And no matter how much we tried we would many times repeat the same mistakes over and over again. And usually our bandwidth was too tight to go deep into each of those issues and find out what went wrong. The responsible person would say that they have done each step as it is supposed to be done. Obviously they did not think that they had done wrong. Because if they thought they were doing the steps, wrong they would not have done it the first time around. No one likes to do the same things repeatedly. Of course many such processes eventually got automated, but till they did, there needed to be a solution. Also not everything can be automated. So we created checklists for every repeated process. And placed them in prominent and easy to find places (physically and in our intranet) This also worked like magic. Soon the number of errors in repeated processes saw a huge fall. Once the errors reduced, the people handling those tasks got more time and bandwidth and they had time to fix their processes and also to automate them. This way the manual process need to be no longer done by a human. This brings us to the next step.
Micro Automations
While it was clear to us long time back that there needs to be a lot of automations in our day to day work, there was one thing that did not allow us that immediately. And that was that automations take time and usually features for customers had highest priority and lowest available times. So when do we spend time on automations? For some time we just postponed the automation work thinking that after the present set of issues are finished, we would have time to work on automations. However we soon realized that this is a mirage and being the startup that were, getting bandwidth for this sort of thing will not be a reality any time soon. But does that mean we abandon it and the benefits that they would bring ? No, what we did was, we took time to make sure that whatever bits we could automate, we would. And make sure that we keep using it unless it was totally unusable.
We made sure we set out to automate only small bits. I call the process Micro Automations. As the name suggests, we only automate a small bit at a time. We also ensured that each bit that we automate is SMART, (specific, measurable, achievable, realistic and time bound). And also we made each bit small enough that it can be done part time by one or two people knowing very well that the main features clearly have priority.
This ensured that over time, we automate more and more bits of processes like our build systems, deployment process, automation tests etc. Bit by Bit. Over time, however we achieved a lot. Finally after all these months, we look back and marvel how much we have actually achieved. As the old adage went, we won the race, by being slow and steady.
There are many more such things that I would like to talk about, but I would like to limit myself to the bureaucratic ones that we attempted. We wanted to make sure that our focus was on the problems pCloudy was supposed to be solving for our customers, while at the same time, we ensured that we were also becoming future ready and being more and more ready to scale further as an organization. Your comments and insights are welcome. I would like to have a conversation about that in the comments section.
This blog and a few upcoming ones in this series will talk about our Devops journey and the lessons we learnt while scaling up in a short span of time.
[xyz-ihs snippet=”quickLinks-scaling-up”]
pCloudy’s DevOps Journey
We at pCloudy have been serving your mobile testing needs for 3 years now. And these years have been a wonderful roller-coaster of experiences, ranging from successes, achievements, near misses, not so near misses, crazy deadlines, demanding customers and above all lots and lots of learning.
We have had numerous challenges at various stages of our journey. Each phase of our journey came with specific sets of challenges and each time we surmounted those challenges, there were many insights, lessons and some time even ah-ha moments. But each of these learning howsoever small have in a way contributed to what we are right now. It has made sure that he product is stronger than ever before and growing faster than ever before.
And this learning is what we feel is very important. After all it has molded us in many ways. And we feel that this set of experiences will benefit others who may want to down the path that we took. This blog is an attempt to do exactly that, specifically with the DevOps part of our journey. I, Prashanth Nair, heading the tech department at pCloudy, will try to give you our perspective on the challenges we faced while building a robust DevOps. And overall this blog is an attempt to give you a ring side view of our thought process behind our DevOps decisions.
This post and a few subsequent ones in this series will talk about specific aspects of DevOps and our experiences with them. Here are a few of the items that we plan to talk about. I will be updating this page with links for those items as and when they are ready. There might be others coming up, keep watching this space for more info. If you have and experience.
For any software development team, a source control is paramount. This post chronicles our scaling journey from a small team that used a simple strategy to the present system where close to 30 developers can work together simultaneously and do not step on each other’s metaphorical toes. It also details the branching policy we setup and how we created our testing and DevOps around the new branching model. Read More
Sir Winston Churchill once said “Plans are nothing, planning is everything”. In the context of a Sprint, what it means is that your team should have a plan to refer to, even if the original plan, the one agreed upon during the Sprint planning no longer is valid. You should constantly keep planning so that, you can react to changes in your present set of conditions that you are working with. How do you reconcile scrum with unplanned eventualities? How do you make sure your goals are still met? How do you ensure that your team is focused on completing the goals even when there are changes in your plan. And how to make sure your plan stays unchanged. This post gives you a look into why and how we pivot, how and why we decide not to. How do we course correct on a daily basis ? And finally how we have our daily Scrum and how it has changed over the years. Read More
Most DevOps patterns are exhaustive and would need some strong commitments, in terms of both time and effort. This usually is also the reason that people hesitate to introduce DevOps to their teams. Because there usually is a lot of change required in your way of working and the way your workflow flows when you try to retrofit a DevOps into your setup. More so if you did so without thinking hard about the consequences. So how did we create a continuous system of delivery? How did we make a system that is robust yet flexible enough to incorporate the needed changes ? Read More
Dealing with howlers and perfectionism. Code review for Dummies
Everybody does code review. But does it actually work ? How did we ensure that our code and our blood pressure stay in top shape, while at the same time maintain a feature turnaround time that allows neither. What were the lessons we learnt ? How much code review is too lenient ? how much is too strict? How do we deal with tech debt ? This blog post will delve into the our style and nuances of code review and also look at the specific problems we faced and how we resolved them. Read More
General purpose tools and how they helped us
This is more of a philosophical rant about the inherent urge that many software engineers have about reinventing the wheel, and how that prevents us from using really good tools that are available in the market causing productivity to suffer. I will give examples of how with the right tools we have managed to speed things up or made things less error prone or less boring or more automated. With each example I will show you how we became more productive with each class of tools and made work that much less difficult. Stay tuned for this upcoming blog in this series.
Let us know about your DevOps journey and how did it help you scale up in the comments section.
Are we not living in an amazing time? Technologically advanced, digitally sound!
We thrive on all things digital. The world around us is becoming all digital with limitless possibilities. Today as a consumer, you can preorder your coffee, interact with augmented reality in the store, and skip the lines at store with alternative payment methods.
To cut the story short, as a consumer, we have access to unlimited goods and services and connected around us. And mobile is at the center of all this change. It’s the tool that is bridging the gap between the digital and physical.
And the availability of 5 million apps come as a proof of this explosion. In the first quarter of 2018, Apple had 2 million apps on App store. As of the same quarter, Android users were able to choose between 3.8 million apps. More and more businesses are adopting Mobile Apps as their primary channel for business growth. This explosion proves that mobile is at the core of customer experience.
Before moving further into the topic, you can watch the entire webinar here or else you can skip the video and continue reading to get the gist of the webinar.
As a business mobile Apps are not just another channel. More and more organization are realizing that it can be a means to create awesome customer experiences. There are numerous examples to illustrate.
One such example is Starbucks.
The secret to Starbucks’ app’s success is that it gives users an intuitive experience, making it as easy to find a store, order your coffee and make a payment through their wallet. Recently, Starbucks has also taken the mobile app experience one step further with an innovative conversational ordering system powered by Artificial Intelligence (AI). The explosion in mobile apps imply to speed. How quickly you can make a change and let the customer experience it? The mathematics of velocity matter here. Market speed has left companies with a simple problem: How do we go faster than we ever have before, without losing an eye on quality?
The success stories like Facebook and Netflix tell us that we can
It is an amazing fact that Facebook mobile app is updated and refreshed every two weeks like clockwork. That’s the new normal. We will talk about this example in detail a little later in the webinar.
So in order to gain Quality@Speed, we reach to a point where experience and quality intersect and we name this convergence Quality@Speed. It’s a no brainer to say that Quality @ speed can be achieved with two fundamental principles.
Agile: Agility allows teams to work closely with business and it Pulls quality forward. It’s also called Shift Left of Quality. You are delivering small chunks to end consumers on weekly or monthly basis. This allows teams to get feedback early on.
DevOps: DevOps brings you speed. It’s a Shift left of operations.
DevOps practices allow you to create “ready to deploy code” on demand. In other words, it means deploying software and the environment on which it runs, automatically and on demand, at any stage of the software delivery lifecycle. You can truly have multiple deployment in a day.
If we dig deeper, DevOps is enabled by two practices Continuous Integration and Continuous Delivery. These two will not work in sync until you have continuous testing in place. It’s also proven by many independent studies.
Here, we have a look at the data extracted from World Quality report, 2017-18 showcasing the popular and the best practices followed in DevOps.
If we have a closer look at the data, we will find that 87% of CIOs and senior tech professionals use or are planning to use cloud based test environment. Depending on choice of organization, it could a Private or public cloud but it’s a must to achieve speed.
Second data point is about Continuous Testing, here as well more than 80% of respondents chose this as a preferred DevOps practice.
Let’s look at what some of the success stories say
Facebook follows Ship early and Ship often approach. They update their web app multiple times a day while their Mobile Apps with frequency of almost 2 weeks. This is possible with DevOps best practices they have been following from past few years.
If we analyze their DevOps story in short, we find that one of the biggest takeaway for Mobile Teams is their massive investment in device infrastructure. Every time they make a change to app, it gets tested on 2000 real devices. Imagine 2000 real devices! They have bypassed use of simulators or emulators.
Mobile DevOps Challenges
Now let us move on to have a look at some of the Mobile DevOps challenges that comes as an obstacle on the way of mobility teams.
Multi-platform Support
Mobile apps have multi environmental target. Mobile apps have to deal with device fragmentation as they need to be workable on multiple devices. This poses a test for Ops team to build an optimal device infrastructure. Moreover, it is difficult to keep pace with the ever changing device requirements.
Mobile apps as an enterprise front end
Mobile apps, that too, mostly the enterprise mobile apps catering to business-to-consumer (B2C) or business-to-employee (B2E) segment of apps, characteristically have very less trade logic on the mobile device itself. On the other hand, a B2C or a B2E mobile app
serves as a front end to enterprise mobility already in use by the firm, such as transaction processing systems, employee HR systems, or customer acquisition systems.
This implies that the mobile app, available on multiple platforms as a native or Mobile Web app, needs to be built and delivered aligned with the backend services. The biggest challenge for DevOps is to think about enterprise mobility holistically and manage their build and release processes and cycles.
The App store
The app store includes an extra asynchronous step to the deployment procedure since developers are not able to update apps on demand. Even for grave bug fixes, new app versions need to pass through an app store submission and review process. Continuous delivery here gets a roadblock and the instant delivery becomes “submit and wait.”
Build Challenges
Since apps today are supported on multiple platforms, numerous different builds of the app has to be triggered each time when a change is being deployed by a developer.
The build system and configuration for each supported mobile environment is dissimilar from the others. You will probably require a small farm of build servers to be provisioned and available to manage these multiple operating system builds.
A typical Mobile DevOps Architecture
Let’s try to depict the Mobile DevOps cycle. Some of the tools mentioned here are a representative set of tools in the respective category.
It starts with a Dev checking in a code to Git/Versioning system. That triggers the CI server to build the App which could be Internal build server or a cloud system like Circle CI. Once the build is successful, Unit tests are runs on Real devices. If the Tests are pass, build is pushed to QA Env. Where Automated regression tests are triggered on real devices. If that’s a pass App compatibility tests for new features are done.
The Evolution
We’ve by now witnessed quite a journey to reach Continuous Testing. “Classical” testing was intended for software delivery cycles spanning months or year. Agile has changed this norm to a 2-week development iterations—but now something extra is required to meet today’s insatiable demand for software. Attempts to fasten the process further, created a chasm between Development, Test, and Operations. That gap has been bridged with DevOps and Continuous Testing in order to move beyond that speeding up plateau. However, when we look into the future, it’s clear that even Continuous Testing will not be enough. We need “Digital Testing” to achieve extra acceleration and meet the quality needs of future. AI can help us get there.
Mobile Testing and AI
If you keep pace with the market buzz you will find there is an ongoing debate about what AI can do? When it comes to testing, lot of theories have started predicting that AI has the ability to replace testing. Well personally I don’t see this happening in near future. But we certainly are very excited about capabilities AI present in from of us.
When we an organization think of using AI to sole testing problems we think on three lines
a) Can it improve speed of current testing process?
b) Can it help generate meaning full data for me to make intelligent decisions?
c) Can it improve the test coverage and reduce cost?
So, are you ready to adapt a personal assistant for testing. So are you ready to say? Certifaya, Can you run an App Test for me? pCloudy’s AI powered bot, can automatically test the mobile applications over hundreds of real mobile devices and gives its users real time insights into the app’s behaviour and performance. Do you want to explore more? Try Certifaya for free now and testify it yourself. You can also go through our webinar on the same topic to understand it in detail.
