1

I would like to deploy our php projects, but I don't know how to go with our typical project.

Our project is based on our CMS. We customize the CMS with extensions(plugins) and customized templates. The CMS core and CMS extensions are in SVN. Customization means, that we do some changes in templates without commiting to SVN. If the SVN version changed, we can update the project to up-to-date version, but usually some conflicts will rise...

Is there an easy way to have an up-to-date CMS/extensions versions in customized projects? Is deploying with Phing or Capistrano the right way?

Please, give me some tips, pages etc. with simillar issues. Thanks a lot.

Jaroslav Moravec
  • 428
  • 3
  • 6
  • 18
  • 2
    Have you ever heard of branches? Or svn:externals for that matter? These will be able to solve part of your problem, while retaining a solid code repository containing your changes for specific clients. When creating a new project : create a copy of your CMS in a new branch or create a separate repository and import your CMS code using svn:externals (or use a vendor branch). When you have CMS updates you can merge these in the clients repo/branch as you see fit. We always use a different repo per client and 1 main repo for our CMS (and that seems quite logical to me). – wimvds May 03 '11 at 09:09
  • Thanks. That's seems logical. But I am afraid of conflicts. I have to consider to make branches/externals. Ideally I would like to automatize merging. Thanks – Jaroslav Moravec May 03 '11 at 09:22
  • 1
    With a vendor branch you can merge the client specific changes with your CMS changes easily. Of course there's no guarantee that there won't be any conflicts, but if you don't move files around or rename them and you don't have client-specific changes that are not backwards compatible, it should be a breeze to upgrade your CMS releases :p. And personally I'd rather spend my time resolving conflicts then to managing a zillion different unversioned projects (been there, done that, never again). – wimvds May 03 '11 at 09:43
  • I totally understand :) Thanks - I am studying svn:externals :) – Jaroslav Moravec May 03 '11 at 09:52

3 Answers3

1

I must note that your way of handling projects goes entirely against the way version control should be used. You should always be able to commit changes - else your versions aren't kept.

On your deploying question, I'd say investigate rsync. Phing is also an excellent solution.

Wesley van Opdorp
  • 14,888
  • 4
  • 41
  • 59
  • We create new project "every week" from the CMS core and the customization takes 1 to 2 months. So we have a several projects and we can't commit projects into one repository... we need to show changes from repository to customized projects. Is it clear? – Jaroslav Moravec May 03 '11 at 09:16
  • Maybe - the SVN is not suitable for this treatment... should we move on Git? Or make some other changes? I am open to accept any idea :) – Jaroslav Moravec May 03 '11 at 09:18
  • wimvds has a good comment, in a nutshell it says how the company I work at handles this. – Wesley van Opdorp May 03 '11 at 09:20
1

This is a build system that we made with phing and we replaced our capistrano deployment system with it. We use Git exclusively and many of our projects use the same build procedures so we wanted a system that we could add to any project as a git submodule and start building/deploying right away. You're welcome to use it and fork it if you want to.

https://github.com/CodeMeme/Phingistrano

Jesse Greathouse
  • 382
  • 1
  • 4
  • 18
0

Create a new repository for each project and use SVN externals to include the CMS core into your project repository. Not commiting code is a huge fail.

cweiske
  • 30,033
  • 14
  • 133
  • 194