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

Re: PHP developers workflow discussion



At some point I would like to help do the same thing for the Python carts as well…
Steve

On Mar 18, 2013, at 3:21 PM, Clayton Coleman wrote:

> 
> 
> 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
>>>>>> $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.
>> 
>> 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
>>> 
> 
> _______________________________________________
> 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]