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

Re: PHP developers workflow discussion




----- Original Message -----
> ----- 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
> > > $OPENSHIFT_DATA_DIR),
> > > - 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.

Can you elaborate on what your plan is there?  There have been several discussions about this - the last I heard here was a strong desire for the cart to infer the correct php directory based on the structure of the git repository.  There should be a default (which folks are pushing for to be www) for new repos, but when someone delivers a repo that has no php dir but index.php in the root, the cart should use the root as the php dir.  If there's a php/ or www/ dir with index.php, then the cart would use php or www. If the cart can't determine, it would fall back to either an openshift marker or not.  Is that all feedback you've integrated, or are you earlier along.

> 
> > 
> > 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
> (https://openshift.redhat.com/community/blogs/release-management-in-the-cloud)
> 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
> > 
> 
> _______________________________________________
> dev mailing list
> dev lists openshift redhat com
> http://lists.openshift.redhat.com/openshiftmm/listinfo/dev
> 


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