I realize that at least one other person has asked this before (and it was suggested to use the archiver module), but I'm looking for some guidance on how to handle version control and content workflow with CMS Made Simple. I have a site I want to manage with CMS MS, but one requirement is that all new content needs to be staged and tested before rolling out to production. What are some good approaches for handling that requirement?
The client for this site is already comfortable with version control generally (they use SVN to manage their site now), which means they know how to stage a set of changes to multiple pages, test them, and then deploy them using trunks, tags, and branches. Is there an analogous (or even improved) workflow with CMS Made Simple?
Version Control and staging
Re: Version Control and staging
Well, that sort of works. But the client prefers to have separate dev, QA, and live environments, so we need a way to stage content across those platforms. Since there's no version control of any kind built into CMS MS, the resulting workflow is now:
1. all developers need to share a common instance of CMS MS. This is a shame, since it means developers have to be connected to the VPN to develop, and no branching is possible.
2. when we're ready for a snapshot, all development halts;
3. the administrator takes a snapshot of the database via mysqldump and checks it & the file system into svn, at which point development can resume;
4. the revision is tagged;
5. the tag is pushed, and testing can begin.
6. once testing completes, the tag is pushed to prod.
On prod & qa, we remove the admin directory, and use some trickery with the debug setting to forcibly clear the cache.
Ick.
1. all developers need to share a common instance of CMS MS. This is a shame, since it means developers have to be connected to the VPN to develop, and no branching is possible.
2. when we're ready for a snapshot, all development halts;
3. the administrator takes a snapshot of the database via mysqldump and checks it & the file system into svn, at which point development can resume;
4. the revision is tagged;
5. the tag is pushed, and testing can begin.
6. once testing completes, the tag is pushed to prod.
On prod & qa, we remove the admin directory, and use some trickery with the debug setting to forcibly clear the cache.
Ick.
-
Pierre M.
Re: Version Control and staging
Hello again,
I'm surprised : in your first post you speak about "a site", "a client"... seems straight simple CMSms to me (admin, designer and editors) ; now you are talking about "all developers" doing "development" (an entire coding team?) and software engineering practices. I hadn't understood that you have a team hacking code.
But wait... there is an opportunity : there must be people in this team who can comment on my post linked to above. They could evaluate the work of the 'versionning patch' (the added "version" and "approval_level" fields, may be the "lang" field also).
Pierre M.
I'm surprised : in your first post you speak about "a site", "a client"... seems straight simple CMSms to me (admin, designer and editors) ; now you are talking about "all developers" doing "development" (an entire coding team?) and software engineering practices. I hadn't understood that you have a team hacking code.
But wait... there is an opportunity : there must be people in this team who can comment on my post linked to above. They could evaluate the work of the 'versionning patch' (the added "version" and "approval_level" fields, may be the "lang" field also).
Pierre M.
Re: Version Control and staging
I run a creative services firm; we implemented a CMS MS custom site for a client. So I have developers working for me, and designers, and the client has IT staff working for the client. There's absolutely no way for me to develop in my CMS MS instance while they develop in theirs.
When implementing these systems for larger clients (this client has at least a dozen people who may edit different parts of the site), there's always a need to keep the live production site very, very stable. So they create a development environment where people can hack away, and a QA environment where multiple changes are integrated. But this all relies on some sort of real version control (like Subversion) that doesn't exist inside the system.
Yeah, when you have a web site that 1 person edits, it doesn't really matter. And if you're only ever going to use it that way, fine -- but this software would be good enough for enterprise use with a few tweaks. Right now, I'm just working around that.
When implementing these systems for larger clients (this client has at least a dozen people who may edit different parts of the site), there's always a need to keep the live production site very, very stable. So they create a development environment where people can hack away, and a QA environment where multiple changes are integrated. But this all relies on some sort of real version control (like Subversion) that doesn't exist inside the system.
Yeah, when you have a web site that 1 person edits, it doesn't really matter. And if you're only ever going to use it that way, fine -- but this software would be good enough for enterprise use with a few tweaks. Right now, I'm just working around that.
-
Pierre M.
Re: Version Control and staging
So I misunderstood from the beginning : I thought about user versionning features and you talk about software engineering.
If you have several code development teams coding software, may be on top of CMSms, I'm not sure your question is CMSms specific : CMSms isn't about software dev workflow, you are free to work your way when you integrate it.
Pierre M.
If you have several code development teams coding software, may be on top of CMSms, I'm not sure your question is CMSms specific : CMSms isn't about software dev workflow, you are free to work your way when you integrate it.
Pierre M.
Re: Version Control and staging
I have worked on other HUGE web systems (Microsoft and working with developer from HP) and they don't have Version Control for the code (VC for the content is a different subject) they all use an external Version Control software like SVN or GIT. and it is done just like the code management is in the forge.
If your workflow doesn't work it is because you don't know how to setup a web development system.
If your workflow doesn't work it is because you don't know how to setup a web development system.
Re: Version Control and staging
Sounds like you may need to upgrade and see some of the newer permissions updates, they may have a way of working for you that you haven't found in the older version of CMS Made Simple...
Re: Version Control and staging
This was a troll comment, if I ever saw one.ajprog wrote: I have worked on other HUGE web systems (Microsoft and working with developer from HP) and they don't have Version Control for the code (VC for the content is a different subject) they all use an external Version Control software like SVN or GIT. and it is done just like the code management is in the forge.
If your workflow doesn't work it is because you don't know how to setup a web development system.
No, the problem is that I want developer A to work on integrating his on-line payment system on a branch while content maintainer B adds his urgent press release to the current production site. If there were no database involved, no problem -- those changes would not touch each other. But the database introduces a problem with the primary key; each html blog has to have its own identifier, and the identifiers come from a sequence. So A and B, each working on their own, wind up with new HTML blobs that have the same ID. I can't just merge the database changes from A into the trunk anymore; instead, I have to reapply them manually to the trunk.
Commercial CMSs tackle this problem by creating a version control feature inside the CMS itself; they let you version the whole site (in a manner similar to how SVN versions an entire directory tree). In that case, developer A's new page and developer B's new page would get different unique identifiers, even though A's changes happen in a branch and B's happen on the trunk. CMS MS doesn't do that.
I'd either like to see CMS MS incorporate a version control scheme (with branching, merging, and tagging), or make some changes that help it integrate better with SVN (or git, but it's next to impossible to get my designers to use git). Not being able to branch is a real bummer.
I'm currently using CMS MS 1.6.2, but I'll double-check on permissions. Maybe there's a way to publish a page such that editors can review it, but the general public can't? If so, it's not obvious.
Re: Version Control and staging
If you read what I said, I was referring to development version not content version.
And for your illustration I stand by my statement that you don't know how to setup a web development system if you are having a developer work on the same system as somebody updating content.
Version Control for content would be nice but as Calguy1000 pointed out in a different thread if you want all the bells and whistles of some other CMS systems then CMSMS wouldn't be "SIMPLE".they don't have Version Control for the code (VC for the content is a different subject)
And for your illustration I stand by my statement that you don't know how to setup a web development system if you are having a developer work on the same system as somebody updating content.
Re: Version Control and staging
here is the thread ajprog is referring to (I think)
forum.cmsmadesimple.org/index.php/topic,36201.0.html
forum.cmsmadesimple.org/index.php/topic,36201.0.html
Re: Version Control and staging
Sometimes the content *is* the function; we're a creative services shop, and we roll out the web site as well as some of the content that goes with it. Yeah, I could put each developer on his own instance of the CMS, and I could put the content managers all on another one, but I still run into trouble when I have to have the developer working hand-in-hand with a content editor on a piece of functionality. Either these things coexist in the same system, or they don't.ajprog wrote:
And for your illustration I stand by my statement that you don't know how to setup a web development system if you are having a developer work on the same system as somebody updating content.
So, let's suppose you're right, and I just don't know what I'm doing. Educate me: how would you set this up differently? What would you do instead? How would you address the problem I noted earlier, where I have both content changes and feature development going on in parallel? I suppose one option is: don't do it in parallel, but that's a quick way to lose a client.
Re: Version Control and staging
Have enough CMSMS environments setup so that you aren't working on the system at the same time as someone else. In a bigger development shop, yes I would probably suggest each person having there own.
Have a central SVN (or what ever version control software you use) like they have here at CMSMS Forge. In the SVN is a export of the database as well. This is log and version all template, stylesheet, and page content. To make it easier for merging you might want to split the database export into several file (should be done easy enough with a shell script).
When developers start working on a project they pull the latest information from the SVN. When you are done with your changes run a diff command against the SVN and check to see if someone has committed changes to the same files that you were working on. If changes have been made merge the changes from the SVN with the ones that you have made and then commit your changes.
Anything that I missed?
Have a central SVN (or what ever version control software you use) like they have here at CMSMS Forge. In the SVN is a export of the database as well. This is log and version all template, stylesheet, and page content. To make it easier for merging you might want to split the database export into several file (should be done easy enough with a shell script).
When developers start working on a project they pull the latest information from the SVN. When you are done with your changes run a diff command against the SVN and check to see if someone has committed changes to the same files that you were working on. If changes have been made merge the changes from the SVN with the ones that you have made and then commit your changes.
Anything that I missed?
Re: Version Control and staging
Yeah, this is exactly what we're doing now, except for splitting the database file. I suppose that would make it easier to detect conflicts during a "merge," but it still means doing manual merges, since two developers each adding a page in their own environment means they'll wind up using the same primary keys.
I'm looking for some way to help automate that merge process, and ideally that would either be embedded in the CMS or the CMS would more readily lend itself to versioning via SVN.
I'm looking for some way to help automate that merge process, and ideally that would either be embedded in the CMS or the CMS would more readily lend itself to versioning via SVN.
ajprog wrote: Have enough CMSMS environments setup so that you aren't working on the system at the same time as someone else. In a bigger development shop, yes I would probably suggest each person having there own.
Have a central SVN (or what ever version control software you use) like they have here at CMSMS Forge. In the SVN is a export of the database as well. This is log and version all template, stylesheet, and page content. To make it easier for merging you might want to split the database export into several file (should be done easy enough with a shell script).
When developers start working on a project they pull the latest information from the SVN. When you are done with your changes run a diff command against the SVN and check to see if someone has committed changes to the same files that you were working on. If changes have been made merge the changes from the SVN with the ones that you have made and then commit your changes.
Anything that I missed?
