 Hi, guys. I'm Vini. I'm a developer at ThoughtWorks. Today, I'm going to talk about acceptance tests using LXC. So I'm going to talk about the problem that we face because of which we thought of the solution that I'm going to propose. So there is a common complaint that comes, that my acceptance tests are passing on my machine. The acceptance tests are passing on the CI pipeline as well. But still when we deploy on the environment, the functionality breaks. So I just want to highlight one thing that, so why does the functionality breaks on deploying to the environment? Because our environment have multiple boxes running the application in the separate servers in the separate boxes. But when we develop on our machine, it's just one single box on which all the applications are running. Same on the CI, we do not invest enough on the creating a proper environment on the CI agent, or whatever machines that you're using for running the CI pipelines. Again, there is one single box that is running all your applications, and the test suit runs on one single box, which is somewhat a replica of your dev machine. So, but when it is deployed on the environment, things break. So this is the pipeline structure, a small snapshot of it. So this pipeline, acceptance test pipeline is the most crucial one because it is taking the code, the RPMs or whatever packages you have, and running the test suit and then it is deploying to the environment. So it is the only check where you are saying that, okay, everything that I wrote is working fine. So it is very crucial to make this pipeline green. So what we did was, so the solution that we applied was, we said that on the CI agent, we'll try to replicate the environment to which it is going to deploy. So we had four different applications, so and on any environment that was there, there were multiple instances of one application. So we thought we'll create a very thin slice of environment on the CI agent, and because CI agent was just one box, so we could not stress it a lot. So we created four LXCs. Each LXC was running one application, and on those LXCs, we could actually run all our runless, and we could knife bootstrap it or run Chef Client on it, and it would actually replicate the entire scenario of the actual environment. So the point that I'm trying to highlight here is that, why do applications fail when we deploy on environment because it's not just the application, the code that is running. It is also the configuration, infra-configuration that goes into the environment, like some engineX version is running there. So there is some engineX version that is running on a local box, and then there's some other engineX version that is running on your environment. So using this kind of a solution, we were using Chef, so you could use your Chef recipes to bootstrap your machine LXCs on your CI agent, and actually replicate the entire scenario. If it goes green, it ensures that my infra-code is good to be deployed on the environment. It is working well with my application code. Also, if the test suit runs successfully, my apps are running in an integrated mode. The benefit is it gives me a faster feedback before being deployed to any environment. Yeah, that's it. Any questions? No questions. Sorry. Thank you.