How do you deploy your Wheels apps?

[bpamiri]

I'm polling the community in hopes to gain a better understanding of how you deploy your Wheels applications.

One of the things we have implemented in the 3.0 branch (check out the develop branch for the latest checkpoint) is a directory structure re-architecture. This is to enable only putting static files in the root and keeping application files out of the root. The desire for this has been mentioned many times and various members of the community have expressed their wish and desire for such a system.

The issue I have with this is how do you expect to deploy your application. If you are deploying by copying the files to a shared hosting account, typically these types of accounts will have a httpdocs or public directory that they want you to place your files into. If you are deploying via a docker image, are you using CommandBox to host your application in the Docker container? With CommandBox we can utilize the server.json file and use the web.webroot element to specify the public folder should be the webroot of the application.

So the dilemma is this, should we make the base structure one that makes FTPing the files to a shared account easier or should we make the base directory structure one that makes usage via CommandBox easier? Sense we are advocating the use of CommandBox for development it makes sense to follow suite for a deployment architecture, but I don't know how this might effect potential users.

I could also envision additional command line options that may deploy the application onto different platforms and arrange the directories into a way that makes sense for each platform.

[chapmandu]

We deploy with docker and commandbox. I'd lean heavily toward modern, secure best practice.

[tsucaet]

We’ve just migrated our Wheels applications to the latest Lucee 6.x using CommandBox, without a proxy web server. Currently, we deploy directly on a Linux server, but we haven’t yet moved to a Docker or containerized environment.

[mikegrogan]

We develop locally with commandbox (no docker yet). We push code to windows server running Adobe Coldfusion and have IIS running in front of it. Would love to change it up, but that's what we have right now.

[bpamiri]

I'll answer here as a user of the framework in my day job. We have a large scale app running Wheels. When we were on Wheels 2.5 we developed locally with CommandBox and pushed code via Jenkins and later self hosted GitHub runner to VMs running IIS/Lucee 5.4 preinstalled. When we moved the app to Wheels 3.0 we maintained the local development on CommandBox and upgraded our deployment strategy to using Ansible scripts to script the VMs that ran Lucee 6 with CommandBox on linux. Basically getting container semantics but still using VMs running in our own data center. I tried containers with Docker Swarm and Kubernetes but working with VMs is just more natural for me. When things break it's much easier to diagnose and get running again.

Since the release of of Wheels 4.0, we've changed this up once again. Now using Wheels CLI for local development (this is a white labeled instance of LuCLI) using Lucee 7 in development. The Ansible scripts were modified to deploy using Wheels CLI with Lucee 7 on the VMs. The VMs get recycled and rebuilt on each push to production which occurs automatically, kicked off using GitHub workflows running on a self hosted runner. We have a load balancer in front of the 5 server farm and the workflows automatically take a server out of the farm, rebuilt the vm, pull latest code to the vm, warm up the vm, add it back to the LB and move on to the next VM on each cycle. Happy to share any of the details of how this is done if anyone is interested.

[mikegrogan]

@bpamiri iri I'm definitely interested in some of the basics if you had anything to share. How that might look. Interested in maybe doing something like this at a smaller scale. We are getting a Linux server setup soon with docker. Trying to figure out the best approach to scripting some of this and setting this up. Thanks.