Posted by purcell on October 17, 2016 at 3:16pm
I support a number of D7 sites. Most of them share a common theme, the modules in use in each site can vary.
To save space and sanity, I set up local multisite on my dev box. In test and production all of the sites are single site installs. I have little or no control over this decision.
The only solution that comes to mind is to copy all files to another directory as a single site install. I can write a script to do this and just run it every time I want to do a commit, stash or really just interact with git at all. I also need to script copying the other way, coming from the single install to the multi so I can pull all updates other people do in git.
Can anyone think of a better solution?
Comments
I think anyone would go
I think anyone would go insane trying to migrate between a multisite configuration on every pull and push. Drive space is pretty inexpensive nowadays. The sites folder on my local box is 46G and most of that is because we always rsync the files directory. We have scripts that automate brining down what is on staging or live environments to local to make managing local sites easier. What issues do you have with managing separate sites locally? Maybe those would be easier problems to solve?
The rub is that about 40
The rub is that about 40 sites use a common theme and a couple of common features. Every time I update the repo for those components, I then need to keep track which of the sites are not at the most current version of the theme and features.
It is a frustrating enough problem that I lean towards just always having the most recent version on a local multisite install so I don't have to worry about forgetting to update a site.
We are trying to work out a way just to push an update to every site when we update the core theme and features, but in the mean time, this was my attempt at a solution.
I feel like I must be missing an obvious solution that is a lot less fiddly.
Ahh. Deployment strategy is
Ahh. Deployment strategy is hard. We probably have a similar setup with over 100 very similar sites. We have a "platform" that we manage that includes core, common features and theme bundled together. Each site is a fork of this platform. We make releases of the platform with version numbers so we can easily see what state a site is in. When there is a release, there's a considerable effort to update all the sites as soon as possible. Updates on the site end up being a merge of the upstream platform. Deploying every release is quite a bit of effort, but with each release and deployment, we like to try to automate a piece of the process if there's time.
We try not to allow sites get ahead of a platform release, but that doesn't always work out based on non-technical pressures. The best we can do is document what the exceptions are for each site clearly in Jira, and clean it up the best we can in the future.
We certainly have our own issues with managing a lot of similar sites, and would love to hear what others are doing as well.