Sysadmin here. I am very new to Trellis. My IT life has mostly been spent fixing programmers’ environments that have either been abandoned or system / security updates broke their setup. Sorry for this very long and extended msg. I am old and my brain is not as flexible as it used to be.
Beautiful environments and frameworks like this are great; however, if you have to take care of it in an ER situation without ever having been part of the setup; to return the SITE/APP back to live is a huge pain. Thankfully, that part is now over.
However, during that process I got to get a closer look on the internals and functionality of the deployed Wordpress site. And it is pretty nice. It is obviously designed for easy usage by teams with Github integration and all that; but it also appears to make a very nice environment for individual developers that just want a really strong and well thought out deployment that handles plenty of things and to best practices for them that some developers may be much less familiar with: These advantages:
constant and high level security
very nice SSL implementation both on nginx site & Certbot side (let’s encrypt)
very performance focused which has truly become a huge factor for end users
and actually easy implementation and configs once you get used to all the files.
So, all these advantages plus more are having me considering whether to just continue using the system for this current environment. And maybe for some others that are just vanilla installations!
This brings me to my first question:
For an old installation which was originally created around 2017 and has not been connected to or updated or anything since.
In bringing up this environment I manually upgraded the files in the App directory and installed / copied everything over manually to a new installation of Ubuntu 22.
From the production server that I have now somewhat (not totally) adulterated with my filthy vi; how to bring back to the development side?
Part of the reason I really like this framework is it makes changes that I have made manually in the past about a million times and it is great to have a template to reuse. Custom Configs for cashing, Custom settings for MariaDB, Custom settings nginx, wordpress, ect ect ect - I can automate much that I do on the server end software and have a nice regular template. I really love this: but one major question: I get the attraction of 1 server 1 deployment; however, I believe in my mind there are only 2 deployments that I care about in my setup:
Local Dev Environment
A single deployment using wildcard with the production(Main Default Site)and the staging site together on one deployment. How easy would this be? And I understand some of the https stuff; but I know it can be set to only badly affect the second site? Can anyone comment about the possibility of this and how bad it would be in affecting features and functionality - just want to understand.
I read somewhere out there about the databases are the only part that is not easy to migrate. I cannot remember where; but how easily do the databases move. I.E.
And I have not even started to know what the general issue is; but we all know wordpress sucks horribly during system moves and database. Is it like I update the staging to the most recent updates and the database to the lates; what now. For some of the sites (esp this first one) I can update the staging site and move it over to take over the production site. what about the changes that happened. Or do I need to download the latest DB from production and then what?
Sorry I am just confused. Would just using plain file copy / sql dump copy ultimately easier.
Right now the development environment parity and ability of teams is a luxury that I do not really need. It this just overkill for parity with local env?
Sorry for the ongoing meandering. I thank you for taking time to respond even if with a single idea/link to a place to look?.
In your case, where you have modified files in production, you’ll need to commit those changes to the repo, and then re-deploy via Trellis to preserve your workflow. In your situation, I’d set up a local dev environment, and manually apply those changes, test, commit, then deploy.
If your project no longer has a working Git remote, create one (eg. Github private repo).
Thank you very much for your quick response and time to read through.
For future sites the Local DEV → GitHUB → Staging → Production pipeline is great.
The sites I inherited which I guess I was not clear about.
I do not have the GitHub environment. Those belonged to the original web designer / programmer. Who is a good friend and still available and can be part of the project; but as it is a build from 2017 or 18 and he has long moved on to newer technologies like node, rest api, and angular. And that he suggested that he would happily recreate the sites now into these new platforms that he is working with.
And having played very slightly (again, I am not a programmer - I am the guy that makes sure the network and computers and programmers’ many pieces of orphaned code continue to work when the programmers move on to play with new sexy languages - which they always do - been doing this since the early 90s LMAO). Those technology look and sound amazing; but the current business side of the house doesn’t really feel like redoing a whole website which is essentially nothing more than a simple pamphlet site into a new tech framework.
So, I am stuck here in the middle with you and the orphaned environment that I am trying to bring over all newly up to date under complete company control.
So, basically from my long rant:
The OG Programmer is available for anything I need. However, he doesn’t have the original repository anywhere and doesn’t even really remember how he deployed the original set up and only through searching through long forgotten emails did he discover that he used Trellis which currently he has no idea about or even remember very much about it. So, how do I reversible create the dev environment from production so that I can get a functioning installation that I can successfully manage and update wordpress and all that without doing it all manually on the production environment.
