[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: PHP developers workflow discussion

----- Original Message -----
> On Fri, 15 Mar 2013, Vojtech Vitek wrote:
> > Hi,
> > this thread is meant to start discussion about the possible
> > improvements
> > for the PHP (and other interpreted scripting languages) developers.
> >
> > 1) Self-modifying apps, built-in installers
> >
> > PHP frameworks often use the self-modifying functionality of it's
> > own
> > source files. Not just for storing the application settings, but
> > also
> > for updating/installing the functionality.
> >
> > As an example, both Wordpress/Drupal have built-in installers that
> > can
> > be used via the administration; so the site admins are able to
> > update/install new plugins and themes on-the-fly.
> >
> > Normally, all the changes are made in the app's source code itself:
> >  Drupal: app-root/repo/php/sites/*/{modules,themes}
> >  Wordpress: app-root/repo/php/wp-content/{plugins,themes}
> >
> > This is nothing we would like on OpenShift, right? Because whenever
> > the Developer git pushes, these changes are all wiped out..
> >
> > So what's the workaround? They could probably use the persistent
> > storage
> > (symlink the directories in git relatively to the
> > - but is that enough? Would that be even maintainable?
> >
> This use case doesn't sound like a developer use case to me.  This
> sounds
> like someone wanting to run software on openshift.  It's a subtle
> difference I know but this sounds a lot like someone just wanting to
> host
> their blog on OpenShift.

Not necessarily; let me describe the most common usecase for Drupal:
- Developer installs the Drupal core
- Developer installs Drupal modules to bring new functionality
  (think of each module as library with it's own API and dependencies)
- Developer doesn't care about source code of any of the above,
  he just wants it running and up-to-date as a stable framework
- Developer creates new git repository (usually git submodule) in the
  app-root/repo/php/sites/default/modules/ for each of his custom
  modules... and this is where the development happens

> In that case I think OPENSHIFT_DATA_DIR is approperate *or* a
> community
> cartridge (which doesn't exist yet)
> >
> > 2) SFTP to the app-root/repo/
> >
> >  - By the way, this is the default workflow used by the Zend Studio
> >    while developing the Zend apps on OpenShift right now..
> >
> > I've talked to many PHP developers about their feel and
> > satisfaction
> > with the OpenShift PaaS and most of them told me they really hate
> > the
> > "slow" git push deployment.
> >
> > They can't develop on OpenShift as quickly as they're used to, so
> > they're basically forced to use their own local Apache for
> > development.
> >
> > This is against the whole PaaS idea; and also far-away from the
> > ideal
> > test/production release management.. See
> > https://openshift.redhat.com/community/blogs/release-management-in-the-cloud
> >
> > What the PHP developers call for is usually the SFTP/FTP access to
> > the app-root/repo/ directory using their favorite IDE to be able
> > to make the changes on-the-fly. Why? The thing is, that PHP is kind
> > of those "Try it and see if it works." languages.
> >
> > =
> >
> > So what comes to my mind to improve the usability for the PHP
> > developers
> > (and to be able to use PHP apps with self-modifying functionality)
> > is:
> > - let them access the app-root/repo/ for development (well, they
> > can
> >   do it right now, until they git push and wipe-out all the
> >   changes..)
> > - let them decide if the app-root/repo/ was git repository or not
> > (means do not remove the .git/ metadata when cloning from bare git
> > repo)
> > - let them git commit/push from that gear's repository using SSH
> > - let them git commit/push from Web Console (as in advanced Cloud
> > IDEs)
> > - let them do the above also using the popular Cloud IDEs (eg.
> > Cloud9)
> >
> >
> > We would need of course to think of the possible git conflicts that
> > would come with the app-root/repo/ git repository. But in my
> > opinion,
> > this all would be wort it.
> >
> We've talked a great deal about making the developer experience
> better and
> it's something we need to get back to after the cartridge format
> changes
> go down.
> So, a couple of things.  They can always symlink app-root/repo/php
> somewhere (though as I understand it we should get rid of the /php at
> some
> point).

Yes, my plan for php cart v2 is to have the public dir changeable.

> Also, and the science here is extremely important, find one of your
> developers and have them time the difference between an rsync (which
> would
> work today) and a git push.  Then have them do the same with hot
> deploy
> and some other bits and report that info back to the list.

What I was referring to was not just about deploying the changes - 
but rather about the on-the-fly development itself.

Developers want to use their favorite IDE, hit the hotkey to save
the changes and "see if it works" in the browser.. And once they
say "hey, it really works", then we can think of them doing any
"manual work" (say git commit/push).

Hot deploy doesn't help there either. It just speeds up the bad
development model. We want the PHP developers to use OpenShift
for development, testing and production
so they don't need to use their own local Apache for development
anymore.. PaaS ready for everything.

> In our experience the bits that take the longest are rebuilding (not
> needed just about anywhere but jboss) and the dep resolving (not
> needed
> for day-to-day development).  So our thought was to just look at the
> repo
> explosion which is pretty fast today. This sort of 'developer-mode'
> workflow is essential and I'm glad you brought this to the list.

Thank you. My plan for php v2 cart is to "hot deploy" every time
except when any of the changes hits httpd.conf/php.ini/binaries. 

>  Keep in
> mind they can sshfs mount their repo directory, that would be the
> 'fastest' way to develop but also produces a poor experience on the
> workstation (latency from saves, etc).
> sshfs
> 511e656de0b8cd0604000322 bqclient-mmcgrath rhcloud com:app-root/repo/
> tmp/
> There's still clobbering of the git repo to worry about there but
> there
> are things they can do today *if* they know what they're doing
> (rsync,
> sshfs, etc).  But we should probably take this to the public list.

Yes! We should find the optimal workflow first and then write a blog
post about it. I'm willing to write it myself once we're ready.

- Vojtech

> 	-Mike

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]