AI (Artificial Intelligence) training platforms

AI (artificial intelligence) is increasingly making its way into cycling. More and more riders within the Talent Performance Group are using these digital AI trainers. Although the ‘real’ coaches are still in the majority, this development continues steadily. For young riders who cannot afford an expensive personal trainer, this offers a valuable solution. Thanks to AI, the Talent Performance Group can also provide more talented riders with free performance coaching and management.

Top AI Training Platforms

Choose Vekta if you are part of a pro team or work closely with a coach, and want to combine the power of next-gen AI with human guidance. Professional teams such as Jayco–AlUla, FDJ Suez, Arkéa–B&B Hotels and GreenEDGE Cycling are already using it.

Go for TrainerRoad if you value structured, scientifically grounded progression.
Select Xert if you enjoy in-depth, data-driven and adaptive training.

Try Spoked if your schedule often changes and you need daily flexibility.
Stick with JOIN (TrainingPeaks) if planning, tracking and coach-led training plans are most important to you.

From predictive nutritional analysis and mathematical modelling, teams are turning to futuristic tech to streamline processes and deepen analysis, as highlighted in the aforelinked feature, with the ultimate aim of increasing performance. Separately, artificial intelligence in cycling apps is far from new. The biggest, TrainerRoad, has been actively using machine learning since 2021 and can nowadays detect a rider's FTP (Functional Threshold Power) using AI. Xert was doing similar even before that, and others like Spoked and Join are the established names among the dozens to pop up in recent years.

Sources
Cyclingnews

Google

Google is applying the “dogfooding”practices and Beta release approach for their Office tools. Canary releases where all applications are first used by a limited audience of (internal) leading users, before spreading them over the world. Before releasing internally, extensive testing has been done by the Google test teams. Source Dogfooding at Google Testing at GOOGLE Google release pipeline

Methodology

Dogfooding Continuous delivery almost everything in Google is developed on mainline.

Environments

For smaller web apps in cloud: Laptop > STG > PRD
For Office tools: DEV > TST > Canary > Beta > PRD

Release frequency

Many Google services see releases multiple times a week,

Facebook

Release frequency

Facebook releases to production twice a day.

Amazon

Environments

development, staging and production environments for Amazon’s digital music retail website DEV > STG > PRD

Release frequency

Amazon is on record as making changes to production every 11.6 seconds on average in May of 2011. Sources Software Engineer in Test (Systems Support) vacancy

Spotify

our workflow from local development, via staging and canary, to production. Local DEV > STG > Canary > PRD Manual deployments, DEV accompanies releases to OPS in person, “get it LIVE aqap” don’t waist time in full-automation. containers are already a way of life. The streaming-music provider has been using containers in production on a large scale. With Docker they can build an image, test that image and then use that same image in production. Cat fooding: use competitors products Sources Software Engineering - Career opportunities – Spotify vacancy

Unbounce

QA and DEVOPS at Unbounce

But as the lines blur between product and operation – as the very name DevOps implies – it’s no great leap to recognize that the environment itself is a part of the product.

Carl continues, “It’s QA’s responsibility to actually push new code out to production, so the DevOps team has been providing them with tools that make blue-green deployments push-button easy. Our QA team can then initiate deploys, verify that the intended change functions as expected, cut over to the newly deployed code, and also roll back if there is any reported issue.“ DevOps QA Is About Preventing Defects, Not Finding Them

QA takes a critical role in this organizational structure because they have the visibility and the directive to push code out when it is working, and roll it back when it is not. This is a very different mindset from QA organizations of 10 years ago, whose primary responsibilities involved finding bugs. Today QA groups are charged with preventing defects from reaching the public site. This has several implications:
•QA owns continuous improvement and quality tracking across the entire development cycle. They are the ones who are primarily responsible for identifying problems not just in the product but also in the process, and recommending changes wherever they can.
•Tests are code, as any test automation expert will tell you. It’s a necessity, of course. If your process is designed to publish a new release every day (or every hour) there is no room for manual testing. You must develop automation systems, through code, that can ensure quality standards are maintained.
•Automation rules. Anything that can be automated, should be automated. When Carl describes Unbounce’s deployment process as “push-button easy,” this is what he’s talking about.
•Testers are the quality advocates, influencing both development and operational processes. They don’t just find bugs. They look for any opportunity to improve repeatability and predictability.
Beyond Functional Testing: Automation for Load Testing, Stress Testing, and Performance Testing

Now we are at a very exciting time in the transformation of QA, because while many organizations have mature processes for automating functional testing, they are only just beginning to apply these practices to other areas of testing like security and stress testing.

In particular, load testing and stress testing are critical disciplines for DevOps organizations that are moving at high velocity. A bottleneck introduced to a critical transaction process on an eCommerce website can bring a business to its knees. You want to do everything you can to identify scaling problems before a product is pushed out to a production environment, and you also want to keep a close eye on performance after it’s been released.

If you are curious to understand how your process holds up, check out this infographic: How Automated Your Performance Testing Is. Where does QA fit in DevOps QA for DevOps is, and probably always will be, a broad term. If you can't independently and automatically validate your infrastructure and application configuration though then there's a massive gap in your approach.