We created a ZF2 project with skeleton app and it works fine for a simple test application. Now we are working on a real project. My question is what we should store in the repository (SVN), the whole project structure or just the new source code? ZF2 comes with a vendor directory which is almost 31MB in size (which has the ZF libraries). Should we store the whole vendor folder in SVN?
This is the first time we are using PHP and ZF so are not clear in how we will deliver the complete project to production from SVN. Also what is the build process if at all exists. Any clues/links to "ZF2 project packaging" is appreciated.
No, don't include dependencies in your repository! Putting your dependencies under version control doesn't do any good, it just blows up your repo for no reason.
You want to add the skeleton to your repository and your own library but definitely not the framework or any other dependencies.
The way to go is to use composer for dependency installation and some kind of build tool like Phing to automate installation of your project.
See the relevant chapter on phptherightway for more information on how to build your application.
The most simple build process doesn't even need a build tool
checkout your project from SVN/git
run php composer.phar install to install the needed dependencies (defined in your composer.json)
But most probably you want to do some more stuff like setup up the environment, deleting some files, etc.
A word about ZF packages. They're not available from packagist but you can install them with composer anyways. You just have to add the dedicated repository to your composer.json as described here: http://framework.zend.com/downloads/composer
Related
I've recently inherited a project build on a particular PHP framework, Asgard. The framework itself is less important.
The code is stored on GitHub and contains the framework files, some of them modified, and a few dependencies. Upon installation, one should run composer install, which will bring the rest of the dependencies.
Most of the custom code is in two folders, located in public_html/modules and in framework/Modules, respectively. However, there are some framework files that have been modified.
The code management/installation procedure seems illogical to me, and I would rather all of the framework code (the specified version of it) would be brought by composer and only the few files be applied on top, as a patch.
Is there some development workflow that would allow me to push to GitHub just the changes, not all of the framework files, and then somehow apply a patch over the framework code when composer install runs?
I'm aware that composer is configured via composer.json and composer.lock, I just don't know how to do the patch.
Also, I don't know how to push just the changes to Git, without including the initial framework files, while retaining full functionality in my working folder.
Any idea would be appreciated.
Thanks.
I've created a Symfony project and pushed it to the github. Now I want to get it from github on another machine.
The problem is that there are a lot of files/folders in Symfony's .gitignore file by default, so my application is broken after 'git clone' command.
I would like to know, what is the best way/practice to store and retrieve Symfony application on/from github. What are the common steps to do it?
You have to download and install Composer on your server.
Keep your .gitignore as default and install your vendors on each cloning.
If your deployment isn't recurrent, you can do it manually by use :
composer install
after each cloning .
If you deploy recurrently or just if you want, you can automate your deployment using Capistrano tasks for Symfony2
I'm trying to add a missing feature to a bundle. Here is what I've done so far:
Spoke to the project owner and got their approval
Created a fork and cloned it locally into a directory outside of my project
Made a feature branch
Ran composer install
Now, the question is, how can I include this into my own Symfony project so that it would be autoloaded? I want to test my changes inside my own project before I send a pull request.
See How to require a fork with composer, to be specific, require a VCS repository as described in Composer docs
Or a bit faster way for improving developing process (which is independent on Github), try using local repositories.
You can archive in two manner:
You can hack the vendor folder replacing the folder of the bundle with a symlink of the third-party bundle
[RECOMENDED] Put in the composer.json file of your project the reference of your personal github project instead of the official version
There is a main application, let's call it APP.
APP has several dependencies (including open source projects and proprietary libraries).
There are multiple clients that use their own instance of APP (on different domains that I manage). Some of these clients use a slightly adjusted version of APP. I implemented this by creating a specific module (let's call it SM) for each client that I just add to their instance of APP (so that I don't change any of the code from APP).
Currently, I've implemented this as follows:
Develop APP locally, use Composer to update its dependencies (composer update), push APP on central repo
For each regular client, pull APP from central repo and install the Composer dependencies (composer install)
For clients with specific implementation, create a new SM (specific module), that has the following composer.json file:
...
"require": {
"APP": "X.X.X"
}
...
Then apply the same steps as before for this SM (composer update locally, PUSH to central repo, PULL from central repo, composer install).
Everything is fine, except for two issues that I'd like to overcome:
composer.lock from APP will be ignored by SM (since APP is loaded as a library in the vendor/ folder, and composer ignores the composer.lock files of libraries); this is not good at all, as I will not be confident that the specific clients will use the exact same libraries as APP.
Each time I fix a bug or implement a new feature in APP (and this happens frequently - a few times a day), apart from the steps that I perform for the regular clients, I also need to rebuild the SMs (since one of their libraries - APP - was updated to a new version that I need to use). This is an overhead since most of the changes that I perform are inside APP (and not SM). So, if it was the other way (APP having SM as a dependency), it would have been working faster (since I wouldn't need to composer update on each SM).
Are there any known workflows or best practices that cover this scenario in order to mitigate the two issues above or at least to decrease the complexity of the upgrade/deployment process?
Please note that most of the steps above are already automated, so my question is not about the automation part, but the complexity of this architecture
I implemented this by creating a specific module (let's call it SM) for each client that I just add to their instance of APP
For clients with specific implementation, create a new SM (specific module), that has the following composer.json file:
It's an application with a client specific module (next to other dependencies).
The application has the module as dependency (APP having SM as a dependency).
And not: the module pulls the application as it's vendor dependency in.
This will only cause extra steps to take during the development phase (your issue 2).
I would suggest to refactor the application and it's modules until you get the following folder structure:
|-application #< the application has dependencies
|-src
|-tests
|-vendor
|-framework #< maybe your application is framework based
|-libs #< more dependencies
|-... #< other modules
|-sm #< the client specific module
This allows to pull in dependencies, which extend "the application" for client-specific needs.
This overcomes your issue 1, because APP is the main repository and contains the lock file. It's essential to lock the versions, so that all developers are bound to the same versions and also for packaging exactly the same set of versions.
So, if it was the other way (APP having SM as a dependency), it would have been working faster (since I wouldn't need to composer update on each SM).
Yes! The need to rebuild the module, each time you change APP would vanish, if you start to "develop inside APP" with module dependencies.
And for multiple clients, simply use multiple application repos, which have a custom set of requirements. 10 clients, 10 application repos, 10 composer.json files. Run composer install no-dev then pre-package each repo and place zip into downloads. Done.
You can use a "container" or "packaging" project here, where the composer.json of each project would include the app and the specific modules. You might utilize the caret or tilde operator to specify a version range for the app ("vendor/app": "^1.2.3") and then simply update and repackage, after a new version of the application is released. This approach should work with the composer autoloading, because the application will remain inside the vendor folder, too. Only a little wrapper is needed, to set the composer autoloader up and switch over to your application.
Or, if the application is really modular. Just package the main application and provide the client-specific modules as extra downloads. With this approach upgrades will have multiple download steps: upgrade app, upgrade modules. Think of it as "wordpress-style" updates/upgrades.
You might reduce the complexity of the upgrade/deployment process further by dropping the composer install --no-dev part on the client machine
by building "client-specific application archives" on the developer machine.
These are basically the "--no-dev" package of the application with all it's dependencies, including the client-specific module(s) = pre-packaged.
Like, Application-v1.2.3-WithModuleAForClientA-v3.2.1.zip.
On the dev machine: composer install --no-dev --optimize-autoloader + zip.
To install or upgrade simply download to the client, extract, execute the upgrade script. Done.
Let me just say this, I'm very new to composer and laravel.
I'm a long time cli fan, so I feel very comfy with composer. I've used npm, ruby gems etc, I see all the benefits to package managers.
Problem is, I'm saving entire laravel dir to my svn repository. It seems kinda redundant, especially vendor/bootstrap dirs.
I also find it uncomfortable to have vendor packages same in every laravel app directory on the same server, I'm kinda missing global gems thing from ruby.
How do you deal with this? Is it possible to have laravel like a shared library on server and then just have app/public directories in each project?
What files should be saved to repository? can composer handle all the dependency installation on production server? I see laravel files come with .gitignore files, where do I get svn version?
Much confusion atm in my head, hope to clear these up, so I can start actually writing code ^_^
First off, as far as I know, it is not easily possible to install laravel and it's dependencies globally. I wouldn't worry about that too much though since composer will cache them so it won't need to download everything for each project you set up.
Vendor directory
The vendor dir should definitely NOT be in your repository. I'm no SVN expert but according to this answer you can ignore directories by doing:
svn propset svn:ignore "vendor" .
Most SVN client software should have a similar function in a context menu or similar.
Deploy workflow
Ideally you checkout the repo on your production server and then run composer update to install all dependencies. If you don't have terminal access or have other troubles with that I recommend you download a fresh copy of your repo and run composer udpate. Then upload it to your server.