Description
Watch this set of Lightning Talks from DevOps Dreamin’.
You can see talks from the following:
Anna Wałach-Dudzic ( Engineering Director CWE) and Evgeny Vladimirov (Engineering Manager) at Aquiva Labsshowcase their code AI checker tool for pull requests. A tool built using Bitbucket, AWS and OpenAI that automatically reviews pull requests, detects issues and provides recommendations on how to resolve the issues.
Adrian King (CTO & Founder at Elements.cloud) talks about the numbers around CRM projects, the financial impact of these digital transformation projects and what businesses can do to make these projects successful.
Sam Chappell (Chief Technical Officer at Performa IT) discusses how DevOps can be used to improve efficiencies, governance and team cohesion – even in SMEs.
Stuart Grieve (Senior Consultant) and Lynette Lim (Senior Delivery Principal) at Slalom talk about how large-scale clinical trials can be enabled with unlocked packages.
Samuel Arroyo Acuña (VP, Product & Technology) at Provar discusses where Provar are planning to go in the future with their end-to-end testing solution for Salesforce to improve the overall quality of releases.
Learn more:
Transcript
Hello, everyone. My name is Anna Wałach-Dudzic. I'm engineering manager and sorry, engineering director. There was a change recently at Aquiva Labs.
And today I want to present you with tool that was developed by Evgeny Vladimirov, engineering manager and excellent quality assurance engineer, DevOps engineer in our company. This is something which is called AI Checker, and let me tell you more about it. So if you are developer, if you are involved in the development life cycle, you probably know about pull requests. You probably know about reviewing each other's code.
And you know that when you do it manually, it is slow, it is time consuming and it's easy to miss issues. And we have a lot of nice tools that are doing some of the checking for us, but some of the checking is not possible with these tools. So we had this vote about what if we have this really terrible code that we are not able to check with existing tools. So on the slides on the screen, you can see a terrible code.
You can see terrible code with multiple mistakes, issues that sometimes were able to be detected by the existing scanners, but sometimes just need to be detected manually because that's how scanners works. So we felt like, hey, guys, we have this chat GPT thing, right? We have this chat GPT thing. So if there was someone with my knowledge, like ChatGPT, who could just do all of this manual work, this manual pull request review instead of me, that would save me a lot of time.
So we thought about it and Evgeny started creating an app which basically works with Bitbucket or with GitHub. And it basically connects with the AWS application. We have nice Docker container, which has everything on it. We deploy it.
And this magical container, this magical application connects with OpenAI, with the version that is paid, the version that protects our data and hopefully is not sold anywhere. And basically the OpenAI digest what is in the pull request, digest all the codes that has changed and provide us with recommendations. And we adjusted it. We did some prompt engineering.
We did some engineering on the levels on how we wanted to describe it. And now thanks to this, when we are creating commits in Aquiva Labs, when we are working with code, when we are opening request, this AI checker is going there and it's detecting the issues that may have been detected by the classic scanner, but usually are detected by the senior engineers or mid level engineers who are just going into the code, digesting what is happening there and figuring out like, wait, wait, this is wrong. And, you know, this really speed up a lot the process for us. I'm not sure about your process, but for us, the pull request review was always something that was dragging down the time to deliver the task.
And with the word of AI checker, in the word of AI checker, we were managed to do the pull request review faster. Now it's easy to focus on important stuff. So we can focus, for example, on business logic in our pull request and not just, you know, on the stuff that could be easily detected by more or less advanced tools. So this is what I wanted to show you today.
This is the small thing that we figure out at Aquiva Labs. You can meet us at the booth and we have two presentations today in the Bridge Room. Robert Zussman will open the day in the Bridge Room and I will be happy to close with some interesting DevOps topics. Thank you very much for your attention.
You can ask me any questions later and have a great day. Thank you. Cool. Thank you very much, Anna.
Next. Mister Adrian King. Do you want the podium mic? Or No. You do. Can you all hear me okay?
Hi, welcome. I'm Adrian King. I'm one of the founders and responsible for sort of product direction and technology at Elements. cloud.
I just want to talk about some numbers in our industry. We spent quite a bit of time recently doing a bunch of sort of internal survey work, basically meta work, looking at a whole bunch of surveys. I just want to talk about some of the numbers out there. So, for successful CRM projects, not Salesforce projects, but across CRM, the best projects deliver at least 10x in terms of ROI, you know, a thousand percent ROI.
That's the number even my CFO would probably get quite interested in. And actually, the average successful CRM project was delivering 4.7x in terms of return on investments. The real challenge, however, is that 30% of projects fail entirely, and 85% of projects don't meet their stated objectives.
So, the first numbers are great if you're in the 15%, but an enormous number of projects don't get anywhere near delivering these type of numbers. And actually, some of them just deliver absolutely nothing. And to be honest, in my career, I have worked on one or two of those projects. Let's put this into financial context generally.
Harvard Business Review and study in 2018, there was $1,100,000,000,000 spent on business transformation, digital transformations. That is an enormous amount of money, and the view at that point was at least £500,000,000,000 of that was wasted, and actually £900,000,000,000 of it was probably less than well spent, but at least even $500,000,000,000 of wasted money in our industry. Now this isn't around Salesforce, but I'm pretty convinced Salesforce is no different from the general trend here. And actually, by 2025, they estimated that we're going to be spending $3,300,000,000,000 a year globally on digital transformations.
And if you extrapolate that, you're looking at basically $1,500,000,000,000 of waste in our industry. It's pretty shocking actually, when you think about how, you know, after fifty-sixty years, we still cannot get a lot of this right. So why? The two top reasons, and there are many reasons, are fundamentally lack of stakeholder engagement and lack of planning.
The interesting thing if you think about that is that basically these projects have failed before a single line of code has been written. So it doesn't matter how good your DevOps process is, it doesn't matter how well you've implemented great tooling, if you actually don't get this right, the chances of failure are quite noticeable. So here at Elements, we've been very, very focused on two things. You need to build the right thing.
It's pointless building the thing right if you're not building the right thing. And so many of the problems, so much of the waste in our industry is because people rush into building stuff without actually having sorted out why they're building it, what they're building, and do they really need to build it. So I basically want to finish this very quick lightning talk with, at Elements, we're very focused on helping you build the right thing. If you want to understand about how you make sure that what you put into your world class DevOps process is actually going to add value, come and see us upstairs.
Richard, Toby, Leanne are upstairs. We'll be very happy to talk you through how we can help you avoid being part of that 500,000,000,000 pounds of waste. Thank you very much. Awesome.
Thank you so much, Adrian. DevOps and Agile developments, come on down. Hi, everyone. I'm Sam Chappell from Performa IT, and I want to talk about DevOps and agile development today.
So very quickly, just a little bit about me. I'm the chief technical officer at Performa IT. So my role is looking after the quality of everything that comes out as a Salesforce, partner. And I've been in the industry for roughly about the last eight years and been through from a developer consultant moving through and hence sort of my journey through and learning about DevOps.
So the first thing I wanna talk about is how agile development works alongside DevOps. And the key focus that I want to to talk about here is culture. As, was spoken about actually in the last slide, culture is one of the most important things to making sure that agile development works, but also that DevOps works. Continuous feedback, continuous improvement, and making sure that everyone is engaged across the business, making sure from stakeholders all the way through to end users that teams aren't desperate.
They're working together and working towards a goal for a project. I think it's just a nice quote there. So what is agile development? So there are five key functions of agile up here on the screen, and they link very nicely with the five pillars of DevOps in the ways that I look at them.
So the first one that I've spoken about, which is actually mentioned multiple times, is around collaboration, feedback, continuous feedback, cross functional teams. You can see how they marry up really nicely. The two next key points are obviously incremental releases, continuous improvement, and automation. They all link up really nicely.
If you think about as an agile development process, we want to be working in sprints, deploying regularly, be it weekly, biweekly, and that works really well with automated testing, continuous CICD processes, pulling everything together. You can start small, but the focus that we want to look at here again is making sure that everyone is aligned pushing towards a single goal. So how does this look in practice? So if we think about a typical waterfall project, you're gonna be looking at large deployments, huge amounts of requirements gathering done upfront, then a large piece of development, then a testing window, and typically, there's not a whole load of stakeholder engagement moving in through all those stages.
What you get at the start is not necessarily or what you ask for at the start is not necessarily what you want at the end. And you might not actually want what you asked for at the start. We're looking at a year long project, two year long project, something like that. So if we move to more agile iterative development cycles, we will then be focused on making sure that we've got that continuous improvement.
We're sharing, talking to stakeholders, talking to collaborators every week constantly, making sure that the vision is always there. We're constantly releasing value to the business as well in that we're building small functional pieces that can be deployed little and often, and that it can be governed as it's moved through. So the one key takeaway that I want everyone to have here is that across enterprise, medium sized businesses, SMEs, if we focus on making sure that we start from the right culture, making sure that we know what the objective is, that we're looking through, and making sure that we start small, build up as we go.
DevOps can start from just putting version control in, which I know a lot of people don't have at the start. It's quite nice and simple to get in to get onto that road, but that starts to build the mentality of everyone collaborating together and moving forward. Thank you. Alright.
Thank you so much. Okay. Next up. You're use podium, or do you want this one?
This one will work. Yeah. This one will do. This one will go. Yeah. We're speak in There's your clicker.
Awesome. Perfect. Hello? Hi. That is very weird. Hello. Morning, everybody. Right. Okay. I hope you can hear me in in my awkward position.
So my name is Lynette Lim. We're from Slalom and this is Stuart Grieve. So today we are not selling any product but actually just illustrating the use of DevOps and using an example of a client to just showcase the use of unlocked packages to manage and enable large clinical trials. Sorry, I can't see.
All right, so how do we ourselves here? So we are actually collaborating with a large organization that is trying to remove the barriers to develop better treatments for common diseases for people by actually transforming the technology that's underpinning the running of clinical trials. So two things. What do we mean by barriers?
And also later, what do we mean by transforming the technology underpinning it? So barriers are, for example, one typical cardiovascular clinical trial is around 1,000,000,000 US dollars to run. So imagine the amount of investment that is needed to actually help to trial run groundbreaking treatments in order to address common diseases like cardiovascular diseases, even cancers and also vaccines for outbreaks, for example. So this is how we found ourselves here.
And the technology underpinning this clinical trial running is actually very old and dated. So here we are in right now helping them to transform their technology with the use of actually DevOps, which is quite for this conference. DevOps in a way such that the organization running the clinical trials have been running trials since 1990s, which means they have noticed that there is 80% of reusability in clinical trials and probably 20 the percent variety when it comes to the various treatments needed and various operations needed to run trials. So this is where DevOps comes in.
Of course, what the previous presenters like Adrian and Proforma has mentioned, you need the right planning as well as the right culture and the right tool in order to do all these things. So we've unlocked packages we picked for this particular project and program. It's a reusable, scalable and modularized solution to run multi massive clinical trials for them in a multi org trial landscape. So what does that mean unlock packages?
If any of you is not sure that's fine. We don't really have a lot of time. You can find us at the booth later. So it basically helps us to enforce package based dependencies validation when we try to roll out massive solutions across multiple different organizations running different type of trials.
Okay so next slide. Although I'm not sure I'm using this thing when a computer is just here. Okay. So how do we find ourselves here?
Next slide. We will have a base package. When I mentioned earlier, there's an eightytwenty template. The 80% of the solution is actually in a core unlock package we roll out to.
Well, in this example, we only have three trials, but in an actual environment, an actual realistic setting is going to be 20 to 100 different trials. Each trial is multi million pound program. So with the base package installed and rolled out and updated like a Salesforce release kind of way, we will have a 20% remaining of configuration for each different clinical trial. And also there is a dependency enforced by nature in unlock packages.
And this is where you can use that type of attribute and properties to enforce dependencies. For example, you may have, let's say, Salesforce release winter twenty four in one environment, for example, and unlock package, have version one or version two in one environment. And if you have a configuration package in clinical trial two, for example, that is dependent on package, call package three, you will know that you cannot install the configuration package without the correct version of the base package coming into the environment. So it's already by nature rule out some human errors when it comes to rolling out solutions for different clinical trials.
So this is where we get to. And then of course the one year of tears and effort and grumbling is what have we learned throughout our twelve months plus of implementation. So I'll hand it over to Stuart to tell you more about it. So as Lynette said, you know, there's been a year of tears and late nights trying to get this thing taken away, aligned to obviously the client's vision of what they're trying to achieve.
We haven't got much time, but obviously we've learned a lot, so I'm going to go pretty rapid fire. Firstly, you can make some decisions about your deployment approach. And once you've got your package created, sure, you're going to be package installing rather than doing source deployments. But as a question, how often are you going to create your package?
Back to version creation is in line with the size of your project and the amount of dependent packages that you've got. And, you know, very quickly, you need to make a decision about how often you're going to do that, as I say. For us, the package creation time was huge, so we didn't have the option to bake it into the CI process. So instead, we opted for traditional source deployments to our initial QA environment.
But beware, once you've got an org with your projects installed via packaging, traditional deployments aren't really supported by, like, typical metadata deployments. Anyone using run local tests on their projects? Close your hands, show everyone's awake. There we go, that's a few.
So obviously these are great. But if you're going to venture into packaging, unfortunately, trying to invoke your tests and your projects this way in an org where those tests are on by package, it's not going to touch it. So instead, you're gonna have to opt for using something that runs specified tests, being able to script getting your tests from your projects. Obviously, naming convention is probably critical here to have like underscore test or something.
Some of you may have heard about scratch or snapshots. If you haven't, it's similar to org shapes, except it includes metadata, installed packages, not just the features and settings. And I mentioned package creation time is highly dependent on the kind of dependent packages that you have related to it. With snapshots, given all of this is baked in from the moment your scratch up is available, it has absolutely huge impacts.
I'm going to be as quick as I can, but there's a lot to cover. So it's not the first time you're going to hear and the last time you're going to hear limitations. Global value sets, I'm going to try and be super quick. Standard picklist fields are supported, but you can't maintain them.
So instead, you're gonna have to ditch them for global value sets, which means you're going to basically have thousands and thousands of them. Vertical solutions not fully compatible. On the studio sits outside of our package, we use extensively, it's quite cumbersome, the gap is closing, but you know, you have to kind of be a bit adaptive stuff. Lots of metadata types aren't supported for just like normal source deployments, unboxed packages, that list is even bigger.
So get used to having to have a bit of a hybrid approach. When you have that hybrid approach, it's going to create a bit of a spider's web of dependencies, mean uninstallations are a real pain in the rear. And last but not least, as the project grows in complexity, things like governance and GA become more pertinent. So you're going to have to have a very kind of methodological way of understanding where new complex features are going to sit in your package hierarchy.
If you don't, things become a bit of a mess and, you know, release notes as well, we found were integral for driving collaboration between developers. Once we have lots of owners and different teams to different packages, you understand an alignment of what's changed from a dependent package and it's gonna be influencing what I build in my package can become a bit of a web. From the time that I rushed through all of that, I'm hoping that I've missed out 100 on things and you have lots of questions. Lynette and I would love to speak for hours about this project because it's been super exciting.
So come see us next Thursday. So thanks very much. Thanks, Mark. Okay. Alright. Last but not least, Provar.
Come on down. I'm not gonna get tired of that. Stay at all. There you go.
Do you want one of these, or you can use one of these? And then it should click her. Yeah. I'm the only one with no slides.
They say it was a lightning talk. Do I need slides for that then? But then he's like, oh, I need to memorize the whole thing, so I'll try my best. I'm Samuel Arroyo Acuña.
I'm VP of Product at Provar. Who knows anything about Provar? Okay, so you probably know us because of our test automation capabilities. But But today, I'm going to talk about a bit more of what we're trying to do at the moment.
So we've had this company for ten years. We've developed our test automation product that works very well to test Salesforce. But we are now, since maybe one year ago, pivoting to thinking about the broader space, and that means everything around quality. So What we're doing right now is trying to get away from just.
Offering a product or test automation and getting into a partnership with our customers in their journey to better software quality. So I don't know if any of these stages will represent you, but usually customers go in a journey. They start from not knowing what they're doing. Let's say they've chosen Salesforce to begin with to implement the CRM, the first thing they need to do is get organized.
The way that teams usually do that is by choosing a tool like Jira or Azure DevOps. Basically, they need to have a way of organizing the project, what they're going to build with their user stories, how they're going to group that into epics, and how are they going to manage their releases, their sprints, and so on. Once they've organized themselves, something that many people don't think about is that testers also need to get organized. And sometimes there is like, Okay, here's the user story.
Developer, you go on your own. The tester, you go on your own. But a tester actually has a lot more work to do that needs to be organized. And we also provide a product for that called Provar Manager.
So Provar Manager helps you not only with your release management in case you don't have Jira or Azure DevOps. We provide a module for basic release management, but the important bit is also test management. As a tester, you get a user story and you need to start thinking about test scenarios. Need to start documenting those so that you may have to do some manual testing afterwards.
So you have your test case with your test steps. But before that, you have to do some planning. You have to do some thinking. So you have test plans where you document, How are you going to go about testing this project?
What types of tests are you going do? Are you going to do like end to end testing, just manual testing, automated testing, functional testing? There's so many kinds of testing. Now we have a test case.
We have test steps, and let's just do it manually. Let's say a company where they do testing manually is probably quite immature in the journey, but at least they're organized. So if you're not helping your quality teams, your QAs, your testers, or whoever's playing that role, get organized. There's a gap in there.
Don't just assume that Jira is enough. They need a way of organizing everything they do about testing. Once you're organized, the next step is feel the pain of having to manually run your tests every day, all the time. The developer comes back and says, this is done.
The tester comes manually, checks everything. It is not done. Here's a bug. Here's another bug.
Developer says, I'll fix the bug. Test it again. Manually go again and again and again. It doesn't scale.
It's just repeat after repeat. If you ask the tester, they probably test everything they know. They're tired of it. The next step in your maturity journey is to automate that, automate as much as you can, and automate as soon as you can.
The moment you give a tester an automation tool, ideally, instead of writing a test case with steps and manually repeating that script every time you tell them to, they will automate as soon as possible. And when the developer says the bug is fixed, I just click run. It is not fixed. Here's the bug.
Run, run. Just click a button. Automate the whole thing. If you want to go deeper than that, you plug QA into DevOps.
So you are able to trigger the execution of those tests as part of maybe your pull request or any other process that you want. And the higher you go on that pipeline, the more you want to test to make sure that you're not breaking something else. Finally, after you've organized your team, your tests, you've been able to automate your test, the last thing is to scale it. Your end users will be using Windows.
They may be using Mac, even Linux. They will be using Chrome, Edge, who knows what. If you don't have the right tools and the right process, you won't be able to test every journey, every script into all of those combinations. So the last thing is to scale.
How do you run those tests into all the different combinations so that you are sure that your end users will not complain? So in summary, what we can help you to do is to assess where you are in your journey, in your quality journey, and see how we can help you to get organized, to automate your tests, and to scale in the cloud with parallel testing. Thank you.
