 Thank you. Thanks for coming to DrupalSouth 2024. We are here to share how the Australian government and the social digital are partnering to make new Gaussian S platform testing easier and better. We will show you the possible ways we have made sure government websites stay strong, safe, and user-friendly. In this session, we will talk about the handy testing tools that are free for all government agencies to use, helping them provide excellent digital services. So, thanks. So before we jump into our presentation, we would like to introduce ourselves. That photo is me, not fake one, but I took it 15 or 20 years ago. So, I'm Joseph, part of a dedicated team at the Department of Finance. We work mostly behind the scenes, ensuring Gaussian S distribution are not only stable, but also secure. Being a provisional member of the Drupal security team, I also contribute to enhancing the overall security of the Drupal project. I'm Steve, you might remember me from such talks as yesterday. I did a talk in the big room. I'm working for Social Digital as a senior DevOps engineer kind of providing some platform services and helping Joseph and the team at finance kind of secure and provide a bunch of services, not just to the distribution but to the whole SAS platform as well. So, in our session, we will have four main points to cover. First, we will look into existing tools for testing Gaussian MS websites. And then second, we will share how to make Gaussian MS sites quicker and more robust. Then, we will focus on how to keep the Gaussian MS sites safe. Finally, we will look at a real example of the Gaussian MS distribution testing project. Gaussian MS gives you a bunch of free tools that help you check your website to make sure it works well, stay safe, and run smoothly. These tools can help you test and check your website to ensure the code is high quality and works as expected before releasing it to production. Let us quickly go over what each tool does. Cypress, the first one, allows you to simulate user interactions on your Drupal website. For example, like clicking buttons, filling out forms, and navigating between pages. It is helpful for testing the functionality of your website from a user's perspective. Ensuring that everything works as expected and providing confidence that your site is user-friendly. PHP Unit is used for testing individual pieces of code within your Drupal codebase, such as functions, classes, or modules. It helps to ensure that your PHP code behaves correctly and produces the expected results. PHP Unit tests are particularly useful for cutting bugs and verifying the functionality of your Drupal sites and the line logic. Now the BeHat allows you to write tests in plain language that describe how your Drupal website should behave from a user's perspective. This test focuses on the behavior of your site's features and functionality, rather than the underlying code. BeHat tests help to ensure that your Drupal site meets its intended requirements and behaves as expected for any users. Drupal Rector automatically checks and updates your Drupal codebase to adhere to more than best practices and coding standards. It helps to ensure that your Drupal site, the code is well maintained, follows Drupal conventions and takes advantages of the latest improvements and optimizations available in Drupal. And then Drupal check. It scans your Drupal codebase for potential issues and security vulnerabilities, helping you identify and fix problems before they cause issues in production. It ensures that your Drupal site is secure, stable, and meets Drupal's coding standards and best practices. Now that we have talked about five available tools, the best person to take us through Ship Ship is Steve. Thank you. So you might be familiar with Ship Shape. It's a tool that kind of validates the configuration layer of Drupal. So it validates the database and any configuration that you export against different operating policies that GovCMS kind of defined for your website. So it says, for example, to meet certain security requirements, you mustn't have DB log enabled in production. You mustn't have this available. You must have a password policy that's set to 14 characters. You must have this. You must not have that. So Ship Shape is the tool that we built with the GovCMS team to be able to define the policies that are required by the websites and then also iterate and manage and run them against all of the Drupal sites in different areas. So it runs in CEI, it runs in pre-deploy, it runs in post-deploy, and then it can also run against the running websites as well to make sure that everything is kind of running and operating as we expect it to. We've got another kind of slide to go through. So yeah, we're kind of working through that and making sure that that policy is continuously updated and we're going to add it into different parts of the distribution as well to make sure that even the distribution layer adheres to the policies that are defined. And one of the benefits of doing it this way is that it allows you guys to have the freedom to build out Drupal sites to meet your client requirements but also have that oversight from GovCMS to make sure that it matches the operating standards that it needs to have to run in production. We've got a bunch of different things here that we're doing to make sure that the GovCMS platform runs in an experienced way. So we're looking at making sure sites are faster by doing a bunch of load testing. So what we do there is we have different websites that are deployed into different clusters within the GovCMS platform that are using different configurations from the distribution. We perform load testing on them pretty frequently to make sure that at least from out of the box the distribution is as fast as possible and we kind of fold that back into requirements within the project itself and can continuously improve and iterate through that, making sure that the distribution is performing optimally and it gives you guys enough kind of freedom to do what you need to do with your sites. As mentioned before, to make things better, we're looking at implementing cross-device and browser testing and so that's where Cypress and stuff comes in. It runs at the moment in the distribution layer and so it runs with Joseph's team in their CI and CD pipelines to validate the cross-device compatibility for the base distribution as well. So it runs in the CI pipeline that they have running for GitHub and it validates against Chrome, Firefox and different things like that. We are looking at potentially bringing that into the SAS platform as well so we'll be able to expose Cypress and allow this. Joseph and I have been talking about this for a long time so we've kind of got it in the backlog to make sure that we can extend that and bring that functionality down to the SAS platform as well to give that functionality into the GovCMS sites. The last thing that we've got up here is mentioned before. The thing that we're using to make sites stronger and more robust from a security and policy adherence perspective is ship-shaped. It runs in varying different places. You probably use it if you're familiar with the GovCMS platform. It runs in GitLab and it will kind of give you a report at the end of your GitLab pipeline and say you're valid against all of the different policies that GovCMS has provided or you breach one and kind of need to fix that before you can actually deploy your site. So it runs there and it makes sure that we're all adhering to the right security standards that we need to run sites within GovCMS. We've got another slide here. Just continuing with the ship-shaped trend. This is kind of like just a general diagram of how it runs, where it runs and what it does. So ship-shape is running against distribution and runs in CI and against environments for projects. And this is just the tool that we've really kind of worked on for the last couple of years to go through. It's come through a bunch of different iterations. You might remember from initial GovCMS days where it was Drutony, then it moved into some bash scripting that we kind of did. Now we've kind of got this open source tool that we've been able to kind of build out and expose and make available to everybody to run. So you can run this for your own projects as well, define your own policies and kind of piggyback off what we're doing with GovCMS to get this working through for your other projects as well. Next slide. So we'll go through some case studies, I think. So did you want to go through this one? You want me to go through this one? Well, so one of the things that we're looking at, this is a case study of how we do distribution testing and kind of the methodologies that we use internally to validate all of the stuff that we're doing for GovCMS from the distribution layer to make sure that it kind of meets our quality before it goes out and is deployed to your SAS site. So the objective that we have, we have two main goals for the testing framework and for testing the distribution itself. So one of the main goals is that making sure that every GovCMS release we do is better without introducing regressions or new problems to the site. So that's where things like Cypress testing, B-hat testing, PHP unit testing, all those kinds of things come into play at the distribution layer. They run through a series of tests there and make sure that no regressions are introduced at the distribution layer. Secondly, we've very recently moved the testing framework out of the distribution itself into a separate repository. And so this has given us a bunch of benefits in that we can make changes to the testing framework without changing the distribution itself. So we can continue to iterate on the test process and do that in parallel to distribution changes. So we don't need to release a distribution change to have additional test coverage and additional test frameworks applied to the distribution itself. I kind of covered the approach, but... And then the technique is so we use a bunch of different automation tools too for the distribution testing. We use tools like all of the tools that Joseph mentioned before when we went through Cypress, PHP unit, B-hat, all those kinds of things, but then we also look at different layers of CI CD as well. We've got like tugboat testing there to spin up environments. We've got CI CD pipelines that also spin up environments as well. So there's testing happening at every layer of the stack that goes through the process to make sure that we've got enough coverage and enough confidence that we're rolling out these sites because where we make a change to the distribution, it's not just one change that we're making. We're rolling that out to 300-plus websites. So we need to make sure that it's working right and it's working well and it's working fast. I think that's it. You want to go back over to Joseph? He can go through the next few slides. This is the most safety part. So thanks, Steve. So let's dive into how this works starting with our CI pipeline design. There are three key requirements in our process. First, we build the GovCMS distribution using the latest code changes. Next, our testing combines automated and manual methods, which is a big part of our process. Finally, we deploy the GovCMS distribution to various platforms, which might be Docker images or ready for use test site. So let's dive deeper into our distribution testing process, especially we can think when we have a new update like a pull request on GitHub to update a module. Our testing is divided into two main areas. Back in testing, here we use a combination of automated tests and manual code reviews. Automated tests include using PHP unit to check issues with new Drupal code updates or PHP updates like variants. The manual code review by our developers adds an actual layer of assurance helping us to be confident about the changes. We also use Drupal Rector to spot any compatibility issues like Drupal Core, PHP variants. Front-end testing, this involves a mix of manual and automated end-to-end testing using Cypress. This test helps us ensure the user interface works smoothly, particularly important for critical security update. Additionally, we use Tuckboot for testing individual pull requests and Lagoon for the final release checks. So this two pronged approach ensures both the front and back ends of GovCMS are carefully tested and secure. Meeting our design requirements from the initial stages. Now we are at the exacting part where we choose the best tools and services for our testing. For automated testing, we use three main CI services. Circle CI, it jumps into action for quick checks whenever a pull request is made or updated. It's like having a fast, reliable mechanic inspecting our car at every take. GitHub CI, aka dependent bot, imagine this as Alex, our recently joined team member who automatically updates our system where there's a new module update or new variant of a library. Alex never takes a break and the ensuring of GovCMS is always up to date with minimum efforts from us. GitHub CI, this is our final quality check before a distribution release. It not only tests everything carefully but also takes care of deploying our Docker images to Docker Hub when we are ready to tag a release. And then, manual testing. Besides the usual local checks, we use Tuckboot for detailed testing on each pull request and Lagoon environments for that final critical review before we go live. This combination ensures our GovCMS is always in top shape, secure and ready for action. I would like to show you a short video that shows our process in action. We will begin from a pull request. Go through the testing steps quickly and end with pushing Docker images once all tests are successful. This will give you a good look at how our CI pipeline works. Let's already start. Oh, yes. I don't have some music. So this is from Alex created the pull request on GitHub. Then CircleCI started to work. So inside CircleCI, we do have different checks from PHP unit to Cypress. We checked everything that we want to know. For example, out-of-date modules of PHP like Drupal coding standards or some errors from Cypress. Inside this example, Alex tries to update our GovCMS from Drupal core or PHP warrior. And we have a failed Cypress test. So Cypress does give you ability so that you can retrieve what happened, for example, inside the video. Now we know some steps could be happened when we want to add a new view. The developer and tester is able to try to do some troubleshooting or trying to reproduce what happened with those steps. It is really helpful for us in such tasks. So this is a target boat. With every pull request, target boat can give us a testing environment for both testers and the developers. So the benefits of doing this is that they are done alone in the moment. We can see it from the front end and we can check from the target boat logs. If the tester is saying something, you need to check. It can make sure the tester and developers can work at the same platform. So here we can see the target boat can give you the logs. So we can see what went around there. Here's the username and password. It can also give you ability to log in from terminal. It's really good for troubleshooting. So after this, the GitHub site, we will move to GitLab. This is regarding to the deployment side. For security reasons, I can only give you some roughly pictures here. So there's a lot of tests here. Once they are all green, we will deploy to Docker Hub. Is the GovCMS distribution like lagoon images? Yeah, so it's Drupal installed into a Docker image with PHP running. And it gives all of the dependencies that are GovCMS in that image that's being deployed. And it deploys the other images too. So it deploys the whole suite. So it deploys nginx, PHP, CI image, which has GovCMS baked into it. Database, yeah. And also Varnish. There's a Varnish image to get pushed for some reason. We don't use Varnish, but it gets pushed because it was there for a while. Thanks. After watching the video, it's very important to mention that we are always working to make our process even better. We have many plans this year, like enhancing our Cypress testing and, as Stephen said, like extending Cypress support to set sites. Also, we are exploring ways to involve more sites in our release testing. With over 300 GovCMS sites, only one test site from us just is not enough. So one key message we want to highlight is the importance of working together. I remember joking with our tester saying, the minute I handle the build over, it stops working. Sorry, it's a bad joke. It's a large-hearted way to say we need to improve our collaboration. So to do this, we focused on four things. I tried to make it as a word, but it's different from my talking. It's clear communication, starting early, used tools that everyone can access, and trusting each other. Whether we are developers or testers, we are all aiming for the same thing, right? To deliver the changes safely and effectively. Yeah, I love the heart, by the way. We also want to use this chance to thank all of our colleagues and give a special thank you to the testers who helped us maintain the GovCMS platform for the public. So here we have listed some useful resources for you. Please feel free to explore these links to dive deeper into the subjects we discussed. The first one is ship ship. The second one is GovCMS tests. So inside the GovCMS tests, I hope that we showed a good example of how we decoupled tests from the distribution code base. So that's all from us. Please feel welcome to share your thoughts or your experience with us. And if you have any questions, please do not hesitate to ask. Thanks. Question outside? So for organizations that are using the SCAFOLG for PAS, are there changes we're expecting to see that we could potentially apply through to what we're doing on PAS? Potentially, yeah. So it'll come via the SCAFOLG. So it'll be up to the PAS agency to merge that back in once the tooling is available, but it'll be available for PAS. Or we haven't, it's still early at this point. We haven't even really scoped out what the change will be yet. So we're still kind of just, yeah, very early in the phase. Javi? So with SAS clients, you said eventually you're rolling out Cyprus. Is that right? Looking to. Looking to. So and Cyprus just wanted to give a head around that for visual testing. So here we have a roughly plan. So what we are having now is that we are at the same page now. We want to do this. But we will have to simulate into different stages. At first, for example, we may introduce a separate image so that people can start to test from their local environment. Then second stage, we could provide a separate image that so people can test it through their CI pipeline. Then third stage, this morning I had to talk with Toby. He's not here. Okay, I couldn't answer it, but if something happened from upstream, he was, he talked about that could give us something that you can view the test results from your dashboard. But that is on the roadmap. So this is some like stages we are going to start. But we will start with, you can start your test from your local environment. This will be stage one. Thanks. All right. One more question only. Yep. Yeah. So I was following up on visual regression testing. So are you using Tugbot to do visual regression testing? So I think Tugbot can be used for different purposes. But in our side is that we are using it for like the shared, like the live instance for both the tester and the developers when we're doing some like troubleshooting. For example, when a tester spots issues, however, it's really hard for developers to replicate the steps. Then we use Tugbot so that, okay, the tester can give us the developers which page, what happened there. Because sometimes the tester cannot give us too many details. By using the Tugbot, our developer, we are able to log into the site, check the logs, and then like troubleshoot to find out what happened there. So this is our usage for the Tugbot. But from what I know is that yes, Tugbot, they have certain features there. You can use it for those like the diff, the differences between each like changes there. Thank you. Thank you. Thank you.