Working with Github & CMSB

Hey Greg,

It's great to hear you've been able to get a good Git workflow going; we've also been experimenting this in our development processes and I'm a fan.

My best guess regarding the repeated upgrades is that it has something to do with your settings files. Upgrades are triggered when the system detects a difference in version numbers between /cmsb/lib/init.php and what's in your settings file. If the version of your settings file on the deployment end has an older version number saved in Git, it could be getting overwritten each time you run the deployment. My recommendation would be to check your settings files (you likely have different files for your development and deployed versions), look for the "programVersion" setting, and make sure it's the same as the version you're running. If not, you can change this and commit it to your git repo.

As for "best practice" there's no 100% correct answer, as different approaches have different trade-offs. The general idea with git repos is that you only want to track files that you yourself are modifying since at its core Git is a tool for tracking file changes. This means ignoring things like CMSB core files, official plugins, uploads, etc. The reason for this is that when you update something like CMSB, you should be able to just transfer all of the files without worrying about what has and hasn't changed. The tradeoff here is that while ignoring these things makes your repo simpler and easy to work with (as well as smaller; uploads and backups can make repos very large), it removes some of the automation from the deployment process. A middle-ground approach is to ignore files that you aren't modifying yourself and also don't get updated very often. This helps keep the repo more maintainable while still saving you the most amount of manual effort.

One thing to note, however, is that once a repo starts tracking a file it is a fairly unintuitive process to ignore it again (and potentially dangerous when working with production environments), so if you're able to solve the upgrade issue and your existing process otherwise works for you, it may be easiest to leave it as-is. And if you do want to try reworking which files the repo tracks, it's often easier to just delete the repo and start from scratch.

Hopefully that gives you some info to move forward with, let me know any questions!

Thanks,

Hey Greg,

When we're getting CMSB ready for release we may end up "building" it multiple times for a single version, so we track individual builds with the programBuild value; it's sort of a secondary version number. Though it's not used for any functionality - just displayed in a few places. As such it's generally not critical if this is incorrect, but it can be used for troubleshooting in some rare cases, so if you're already updating the version number I'd recommend updating this as well.

Cheers,

Hi Daniel,

That's useful to know, thank you.

Regards,

Greg

Hi Daniel,

I have decided to commit everything to Github as I am using private repos that only I am accessing.

The one thing I noticed is that if I make any changes to the database tables using Section Editors on the live website then this updates the .ini files in /cmsb/data/schema

These changes are then not transferred to my repo and so are overwritten when I next push from my local machine.

The answer is to run a local version of the site, make any settings changes on the local machine and then push to the repo and then git push to the server.

I don't feel like I have a completely slick workflow yet but it's fairly good and I will continue to improve over time and will try to remember to share what I learn here.

Regards,

Greg