[Music] [Natalia Angulo Herrera] Welcome to this talk called Rapid Feature Releases with AEM Cloud: Telegraph Media Group's RDE Strategy. On this talk, we are going to present how our customer, TMG speeds up releases by using RDE environments. And we're going to show a lot of value that they just got from this new product at Adobe.
So in order to start, I'm going to introduce myself. My name is Natalia Angulo Herrera. I'm a Senior Software Development Engineer at Adobe. And I'm just mostly involved with the customer experience improvements that we have been doing in Adobe Experience Manager.
Damien. [Damien Ryan] Thanks, Natalia. And my name is Damien Ryan, and I'm the Engineering Manager for the TMG website. So we look after the website telegraph.co.uk and the CMS that powers all of that, which is Adobe.
Great. Thank you, Damien. So what's the best to start, what are we going to be the takeaways for this session? So actually, there are going to be a lot, but the three main ones that we want to highlight here are, first of all, we are going to show how our customer TMG's cloud development cycle has been reduced from 90 to 10 minutes. So a huge improvement over the development. Second part is we will show how actually, in general, not only for this particular customer, automation is boosting developer productivity by 81%.
Last but not least, third point is how development frequency translates to innovation for the business. So these are the three key takeaways that you will just get on through this session.
And now back to Damien.
So you might have heard of Telegraph.
If you haven't, it's an award-winning multimedia news brand. It's been synonymous with quality, authority, and credibility for more than 165 years. It's been around forever. And subscription-first business, which is quite rare for the UK. So our users subscribe to and pay for the quality journalism that we produce.
For digital publishing, we use Adobe Experience Manager as a cloud service. And that powers our flagship products, the Telegraph website, which I've mentioned, and the Telegraph app.
So we're here to talk to you about RDEs and some cool technology. But I want to pull the lens back first, why we do technology.
And we're here to produce value, essentially, for our customers.
And to do that, we want to evolve, we want to get better. So we pull ideas from everywhere. And every idea goes through a process before it becomes something real that can be in the hands of customers. So someone has an idea, says, "Oh, it would be great if we could have a really big headline on the front page of the website." Then we test that idea, we see if it's got legs, and we develop some code that will implement that idea. Then we test it, make sure it all works really well before putting it onto production. So behind every little idea that everyone has, there's a big cycle of work to make that reality.
And then when we were looking at our own cycle, our own process to get through this cycle, we found our biggest constraint was the development/test cycle. So having ideas is easy. Once it's at production, that's great. But going through development and testing and getting that perfect before it goes on to production, that's where we were spending most of our time.
Yeah, that's amazing. And also talking about how to go to production and how to go and...
do your development side. We are going to start talking about how traditionally AEM development works. So basically, we just the local engineer, we're working on their local laptop by using the local SDK. So that was good because you then just deploy and get feedback within seconds. So it's super quick, and then you can just develop. But the problem is, what usually happens is it works on my local laptop, but it doesn't work on the cloud. So it's a problem. Because basically, we are in the AEM, local development is missing parity. So for instance, there are cloud-only features that can be easily tested because in the AEM cloud services are just, we have microservices over there, that at the end, we can replicate onto your local laptop. Also, even that you might not be testing on your local SDK, and last but not least, maintaining a local SDK is time consuming and painful. So you always need to be checking the local SDK version that you are running and downloading everything and then running it locally. So it's a lot of engineering work as well.
So after the local SDK work was done traditionally, then the engineer just go to the cloud and run a pipeline onto the dev environment that actually just builds, validates, and deploy your feature, and it takes a minimum of 30 minutes. So the problem might be, again, if it works in my local laptop, but it doesn't work on the cloud, then you are just wasting a minimum of 30 minutes to say, "Hey, it is not working on the cloud, just because of some disparity or whatever." So this is very time consuming, and it's not the vision that we had to improve for developers to go beyond.
Just because of that, then we decided at Adobe that we were missing some improvements here for the customer experience, and we decided to create a new environment type so that customers can just buy and create several ones. There is no pipeline or git associated. So basically, there is just an environment where you just deploy directly via your local laptop. We'll see. We also support changes at runtime. So basically, you can just deploy configurations, bundles, webtier config, dot, dot, dot because you can just deploy the same as you can do for any other Dev/Stage/Prod Environment.
And we will have quick feature validations. So as I was saying, basically, just a quick deploy code via CLI so that you just connect directly, and there are no any other waitings behind the scenes. This is just done via a plugin that you just install, and it's very easy to be maintained.
So how did the new ambition actually for the new AEM development in the cloud, cloud based? It will be that now you have your local laptop, and the engineer is still working on it, of course, and then you just deploy to directly the RDE environment, which is a cloud-based instance. Then you just get quick feedback as well between seconds to minutes. It depends how if you are just deploying a configuration or a bundle, it's going to be seconds. If you are deploying a big content package, it can be a couple of minutes. But yeah, if you want to learn more, please scan the QR, and then you can just get the link to the public documentation.
But then, actually, customers just saw the value of these new RDE environments, and they just thought about, "Hey, what if I go beyond that?" Because okay, being able from my laptop to deploy to the cloud, that is good, but what if every time that I just develop a new feature, as we can see on step one, I just create a branch of my git repository, and then customers can just set up their own continuous integration pipeline, of course, with Adobe support because we are there to help. And then they just, every time that they open a pull request and have a feature development in progress, they just run this pipeline, the Maven build to build the package, deploy to the RDE instance, and then run some end-to-end tests. If this process is completed and really a success, then they can just call the feature code complete.
It is quite huge testing, more than just doing it manually by every developer. And then they are ready to merge a git branch into the main branch, and now go beyond the dev, stage and prod. But basically, because they were already testing it on a cloud-based instance...
It is likely that it's going to be behaving the same on dev, stage and prod.
So this was the automated end-to-end cloud-based testing that customers were envisioning, and actually they saw the value on that, and they were just go for it as our customer TMG, where Damien will explain more.
All right. Thanks, Natalia. So let's wind the clock back a little bit to 2023, which was such a long time ago. So in the first half of 2023, we moved from AMS. So we've been using Adobe services for a long time. So we moved from AMS, all running on-site, to Adobe Cloud.
And at the time we had all of our environments were full dev environments because that's all we had.
And our deployment time to the cloud was roughly about 90 minutes. Someday, as Natalia said, sometimes it was 30, but it worked out about 90 minutes. So we have all of our automation inside of Jenkins, and that's been working for a long time. But as you saw the time was creeping up.
This meant that our test cycle basically took a day to check that something was working.
So by the end of 2023, as we're looking at our whole development/test cycle...
Natalia came along and said, "Hey, have you tried these RDEs?" So we had a look and thought, "Let's give them a go." And as of now, 80% of our environments are RDEs. So they've been a great success to the point where developers look at all of our environments and go, "Can I have an RDE?" So I don't really want to wait for working on a full dev environment.
And our deployment time is around 10 minutes. So it really tightens up that test/development cycle.
And then that shrunk everything down to about half a day to go around these loops, get something ready to push to production.
And then we went even further.
This works really well for developers pushing their changes. We're still using a full dev environment for our continuous integration automation.
So it's a full three to four-hour run at the time, which would do everything from code quality to deploying to running a huge suite of tests. But a big chunk of that time was waiting 60 to 90 minutes to deploy.
And that meant we only really had six attempts to merge some code during a day.
So we're going to do six changes during a day...
Which meant that we got very, very timid about what we would change.
So we just swapped out the full dev environment for an RDE environment. And that's brought that deploy time down to 30 minutes.
So our full end-to-end then takes 2 hours to run, which gives us 12 merge attempts per day, which means that we can do lots more and push more value through that system.
And don't take my word for it. So this is some data from our automation system.
The red line is using that full dev environment. So you can see at the start when we started off with Adobe CS and full dev environments, it was fine. We were only spending a couple of hours waiting for each build. But as we want to do more and more, so more tests, more quality checks, that time crept up to about four hours.
So at the same time then we brought in RDEs, that's brought it back down to two hours. So we can keep getting those changes in. But there's something you will find with this. There's something called Jevons paradox. So the more efficient that you make a process, the more you're going to want to use it. So you can see that time creeping up again. But instead of using that time waiting for something to deploy to Adobe Cloud, we're actually using it to actively test our software and test our changes, which is much higher value.
Let's just bring it back to what the tangible benefits that we found.
So we have the cycle time per change.
Our change/deploy/test cycle takes minutes now, not hours. So we can make more changes, be more experimental, and try lots more things to get that perfect thing out.
We can run more automation. So we're much more quality focused. And we can really, really be sure that any change we make when it gets to the end of that automation is going to be great for our customers.
And we can deploy more changes every day and every week, which means we can get more features done in the year and provide much more value to our customers.
All right. So that was an amazing user story. Thank you, Damien. You're doing so great. And also, thank you a lot for telling today.
So basically, let's now talk a little bit because we have a great story for a customer. But I just want to say that actually, if we look at our DORA metric for the RDE environments usage, we can particularly look at the deployment frequency and we can see that this is not only a particular customer who is just engaging and making it more success with RDEs. Actually, if we look at this number, we can see that we customers who are using RDE environments, they are increasing 81% their production deployment frequency. And I want to pause it here because I want to look at that number. I mean 81%. That's a huge number and a lot of value. I just want to keep just looking at that number. That's impressive. And actually, that is something to consider and to provide value for your product development particularly.
Not only that value that you can just deploy to production more frequently and deploying more features as well. Also, that actually we are in continuous development and improving things, adding more and more features to the RDE environments. One of them that I want to highlight in this talk is something that we are currently working on. So this is an upcoming feature, is the ability to take RDE snapshots. So basically, our ambition, and actually this is something that our customers asked for, and we just hear them, we saw the value again. And we are working on actually providing a way so that customers can tell, "Hey, I'm going to create a snapshot or the current status of my RDE environment." And they just create a snapshot. And then they just continue going with the RDE environment. At some point, they just say, "Hey, I want to go back to my previous state. So I'm going to actually to apply a snapshot." And then automatically that snapshot is applied and the RDE content is restored from that port. And then they can just start over and start over.
So again, this is work in progress, so it can just change without any notice. But yeah, we expect it to have it soon.
Not only upcoming features, let's also highlight one of the recent news that we got for these environments.
You can see actually that one thing that we also implemented was to have the ability to create loggers and set up log levels for the RDE environments. So that you can just say, "Hey, I want to debug it. I want to see what is going on in my cloud-based environment for the RDE." And then I just want to enable some of the logs, just set up the debug log level. And then, boom, automatically, you just get the log in a stream. And then you can see all the things that are happening there. So in the end, it's like a log life, let's say debugging life, right? Because you can just play a lot with the loggers. This is super useful for debugging, and this is super useful for trying to catch up issues that are happening on your cloud environments. Again, if you want to learn more, please go to the QR, and then you will just get more information about the login.
So I started this talk particularly with the takeaways. So let's just see if we just did it. Okay, so the first one was, yeah, let's explain how the TMG got the development cycle that we used from 90 to 10 minutes. Yeah, Damien was just explaining about that.
Second point was the automation. How developer productivity is boost by 81%? Yep, we got it. That was our metric, that we just had that value for not only this customer, but for every customer that is using RDE environments. And the latest, the last takeaway was how development frequency translates to innovation for the business. Yeah, we saw from the beginning until the end, how this innovation is happening, right? How we are transforming the new development in AEM.
And just to end up with the talk, I just want to tell you that actually you can find us on Discord. The RDE engineers at Adobe are there, especially or particularly me.
I'm also there. So if you have any feedback, any question, any trouble, anything you want to just let us know, and then we are there to support you. If you also scan the QR, you can just get the link. It's a public Discord channel. So then you can just go to #aem-rde and communicate with us. And again, thank you, Damien. Thank you, TMG, for this great session. I appreciate again our collaboration together. Let's go for more. Thank you.
[Music]
