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

Re: PHP developers workflow discussion

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.

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

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.

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.  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.


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