First let me say that as of right now I still don't have all my new custom Sprout Forms field on the server. Partly because it's late and I'm tired, partly because I'm scared. See, like more people with a shared host account not only is her main site on the server but also a couple of addon sites and then this subdomain I made for development. I don't want to mess this up.
So since my colleague Sean is the guy who's all 'craft this' and 'repo that' and 'composer does' I asked him what's next. He uses DeployBot to move files directly from the repo and part of the process involves running a composer command.
Groan, repo. Yes, I've used repos. Yes, I've got accounts on all the major players. Yes, I see the value of using a repo with a team of developers. No, I am not well versed in the world of repos.
I first went to GitHub (I'm not sure why) and did you know you have to pay a monthly membership to have private repos? No thank you.
So I went over to Bitbucket and the comedy of errors commenced. I'm going to assume you already know how to repo or that you can google better answers than I could provide but here's a list of everything that went wrong:
And hey check that out, /vendor
is listed in .gitignore. This article gives a lot of great explanations but this part really stuck and helped explain so much about compiler:
So if we’re not checking any of our PHP packages in the /vendor directory into git (this includes Craft CMS itself, remember!), how do we update and deploy things?
By embracing Composer, that’s how!
We’ll take advantage of how Composer works:What composer install does is look at whatever is in the composer.lock file, and if it’s newer than what it sees installed locally, it updates & installs it! The neat thing about doing it this way is we have less cruft checked into our git repos, and we can also discretely update only specific things.
- In local dev, we’ll update everything via composer update (or we can update just specific packages via composer update packagevendor/package)
- The above step can also be done via the AdminCP UI by clicking on Update, either for Craft CMS itself, or any of its plugins. Under the hood, it ends up running Composer just as described above
- This causes Composer to download & install the updated package(s), and then it writes out what’s installed to the composer.lock file
- Then we test everything in local dev just as we used to, to make sure it’s ready for prime time
- Since we ignore all of the /vendor directory, the only thing that will be changed as far as git is concerned is the composer.lock file that lists what versions of what packages are actually installed
Ok, half way there.
I went to check out DeployBot but it's another monthly paid membership. Again, no thank you. Sean referred me to our other colleague Mike and he uses buddy.works. I mostly followed this article but had to fly by the seat of my pants so I'll try to describe below.
As I said earlier, I can't mess up this deploy because the client has about 5 domains on the server. I put files in the wrong directory and I'm messing up one of their other sites.
I decided to create a test repo with a single file and SourceTree it up to bitbucket.
I created my buddy.works account and started a new project connected to my test repo.
And this is where buddy.works gets interesting. Basically you use buddy.works to create actions to perform on a repo pull. Before any actions are executed files from the repo are pulled into buddy.works filesystem. Actions then take place in the file system. Actions could include shell commands to the file system, compiling the code, and moving files to a server via ftp.
My first test was to move that lone test repo file to the dev environment of the client's server.
My next test was to add a directory to the repo and buddy.works it all up to the dev environment.
Then I started thinking about the file structure of my project repo. When I set up Mamp and craft on my local machine, I left the /web
directory name, which represents the web root. The dev subdomain on the client server is /dev.clientsite.com
. So while the repo is in the buddy.works filesystem I'm going to need to change that directory name.
Remembering back to my university days and unix machines a simple
mv old_folder_name new_folder_name
should do the trick. But after running this test a couple of times it was making /new_folder_name/old_folder_name because mv
will refuse to rename a directory to another directory if the target directory contains files.
But I don't need the files in the target directory. The files from /old_folder_name are what I want to use. My final, and successful, buddy.works test has an action that deletes the target directory (if it exists) and then changes the directory name before pushing to the server.
rm -rf new_folder_name mv old_folder_name new_folder_name
And a-check a-mark.
So I'm hoping that when I get the courage to apply all this to the project repo and move a bunch of files to the client's server I know what's up. Fingers crossed. I'm going to start by making a backup of their 5 or 6 sites.
© 2024 - Amanda Lutz * Web Developer