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

Re: PHP developers workflow discussion

On Mar 18, 2013, at 12:48 PM, Vojtech Vitek <vvitek redhat com> wrote:

> ----- Original Message -----
>> From: "Clayton Coleman" <ccoleman redhat com>
>> To: "Vojtech Vitek" <vvitek redhat com>
>> Cc: dev lists openshift redhat com, "Mike McGrath" <mmcgrath redhat com>
>> Sent: Monday, March 18, 2013 3:32:03 PM
>> Subject: 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
>>>>> - 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.
> The idea of having www/ as default public dir is far better than the
> current php/ directory. The other alternative would be also public_html/
> directory to which many users are used to from most Unix-like hostings.
> Honestly, I didn't think of any advanced logic behind that to recognize
> every possible use-case.

Yup - I think the case we're most concerned with is that most real world php apps in their git repo form should at least start if a user deploys them directly from the upstream repo (although many will require config).

Since there is no dir standard, we know we can't solve all possible cases (user intervention is at least required).  But the following three *should* work

- my repo has no php dir and index.php in the root (Drupal / WordPress / a number of others)

- my repo has a php dir 

- my repo has a www dir

We'd need to ensure we have a clear sequence rule so that people don't suddenly get broken if they add a directory, but that's solvable I believe.  

This is all about reducing the number of special things a dev has to know about Openshift - that is part of our whole 'no lockin' cloud position.

> My plan was to make the httpd.conf (or at least
> part of that) changeable to the developers, so they can change the
> default values, any additional directory mappings or Apache settings
> themselves if they really need to.
> The main idea is to give the Developers as much freedom as we can offer
> them. Once we give them ability to change all server contexts
> (meaning also server config and virtual hosts; not just directory context
> and .htaccess), I think then we'll go for the win.
> What we have in v1 cart gear now is:
> ./php-5.3/conf.d/openshift.conf (readonly)
> <Directory "/var/lib/openshift/<USER>/app-root/runtime/repo//php">
>  AllowOverride All
> </Directory>
> What I'd like to reach in v2 cart gear:
> ./app-root/conf.d/*.conf (writable by developers)
> In the best scenario having the symlinks or Includes to the
> ./app-root/repo/.openshift/conf.d/* so every app can have it's Apache
> specific *.conf settings in git.
> The question is:
> What are security considerations for not letting the developers touch
> any of the Apache *.conf files? And is there anything we could not be
> able to override (after the mentioned Include directive)?
> - Vojtech
>>>> 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]