Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
I'm currently working with Git, Git Flow, Gulp and Bower. I'm working on the develop branch and create releases with Git Flow to the master branch. So develop is equal to my local and test environment, release/version to the acceptance environment and the master branch is equal to the production environment. See: http://nvie.com/files/Git-branching-model.pdf. On every environment runs Git, so deploying is nothing more than: git pull origin master.
I've got some dependencies like Bootstrap and Font Awesome handled with Bower and I'm using Gulp to watch .less files for "compiling" to css, minifying css/js, etc.
Now toward to the questions: what should be in my Git repository? Let's say I'm working on a Magento project, it would be overkill to put Magento and all dependencies from Bower in the repository. Currently I'm excluding only the node_modules (for Gulp) and bower_components (contains dependencies) directories, when I run Gulp the .less files from Bootstrap will be "merged" and "compiled" with my project related .less files. The "compiled" .css file is currently included in my repository, else it's not possible to do a deploy with just git pull. To get it working without having the "compiled" version in Git I've to run Gulp on the production server.
What is the best method for not having my platform (Magento or Wordpress) in my Git repository, but keep the possibility to easily update? I came across this solution: http://blog.g-design.net/post/60019471157/managing-and-deploying-wordpress-with-git where they're using Git Submodules. Nice solution, but this way the platform needs to be in a sub directory. Not ideal because I've to "hack" to get it working that way (copy the index.php and change the include paths, etc).
What about plugins/modules? 3th party plugins shouldn't be in my repository too? Only the plugins I've created by myself. But not all 3th party plugins does have a Git repository to use with for example Git Submodules. For Wordpress it's just one directory, so in theory it's possible but for Magento the most plugins aren't just one directory (they have files in the app/code, app/design, skin, etc directories). I've a lot of Wordpress and Magento sites with multiple matching plugins/modules now every plugin/module is in each sites repository.
Should "compiled" files be in a repository? If you ask me: no, but I'm currently doing it so it's easy deploying. Is it general to have Bower and run Gulp on a production server for dependencies and to "compile" on the production server right after a git pull? Continues running a Gulp watcher (like I do locally) on production takes some extra unnecessary resources?
I hope someone can put me in the right direction.
It's difficult to provide a universal answer that works for Magento, WordPress, and other platforms. My answer primarily targets Magento, but I'm sure that similar concepts could be applied to WordPress and other platforms.
It's possible to automatically install Magento as a dependency using Composer with magento-composer-installer. You can either use a public mirror, like this one, or set up your own repository. Once you've installed Magento itself as a dependency, it should be very straight forward to update it, just like any other dependency.
You can use Composer for modules as well (after all, Magento itself is just a bunch of modules and a few scripts to glue everything together). FireGento has a lot of common Magento modules which can be used with Composer out of the box. You can also set up your own repositories to use with Composer (we do this for internal modules that we use for multiple sites).
As for modules that don't have their own repositories, well, you have three options: don't use them (the less modules, the better), create your own repositories for them, or just commit them along with the rest of your codebase.
In an ideal world, your repository should only consist of your own source files. Everything else - whether it's compiled, installed through a dependency manager, or otherwise somehow automatically created - should not be in the repository.
But we don't live in an ideal world - it's painful to run Composer, Bower, Git, Gulp, Sass, and everything else that you're using on each and every environment that you want to deploy to (development machines, testing server(s), staging server(s), production server(s), and so on).
And what if those dependencies have dependencies? What if you're using a Gulp plugin that works well on one of your servers, but fails on another one? What if someone makes a deployment and forgets to run some of the required builds via Gulp? Of course, the answer to these questions is testing and automation. You should be able to click a button (or type a command, for the purists) and have everything automatically deploy - a git pull is issued, the appropriate gulp commands are run, and so on. But unless you have the manpower and manhours to set up such a sophisticated system, it's not worth it.
Overall, we use a combination of the different points above. In the end, we end up committing (almost) everything to the repository - resulting in deployments as simple as git pull or svn up. Of course, configuration files (credentials, .htaccess files, and so on) don't go in the repository, and neither do fingerprinted files (which we manually upload).
Fabrizio Branca has an excellent blog post here which goes through many of the described points in order to clean up and upgrade a Magento setup.
Related
I am looking to integrate version control into my Wordpress development workflow. I have experience with Git in rails application development, so that seemed like a good option. However, I haven't found any holistic information that pertains to my needs and is in my knowledge level.
I would like to be able to accomplish the following:
develop site locally(I would only be touching the theme files for the most part, so I would want to look to the production environment for the rest of the files to avoid redundancy)
have Wordpress look for theme information in my repository (most likely will be on Bitbucket, but am open to server hosting solutions)
I hope that I am describing this clear enough for someone to have insight. If not I am glad to go into more depth of my goals.
You can refer to "WordPress + Composer + GIT"
It uses (in addition of Git) Composer (a dependencies managing tool for PHP), and WordPress Packagist (a repositories site that automatically packages the plugins and themes available in WordPress site in the format required for working with composer)
That way, you keep a declarative approach where you declare ion a composer.json what you need: this is easier to version in a Git repo.
I am developing a wordpress theme. I am new to using Grunt and composer for packages.
I have also integrated git flows. At the moment I am developing on develop branch and then merge to master once I am satisfied with the code.
The problem I am facing is that my master branch has Gruntfile.js as well as package.json in it. Similarly there are sass files in css folders. I want a clean release branch, in which there are only required theme files and no gruntjs, pacakge.json and sass files.
These all files are being tracked in master, how can I create a clean release branch.
I have followed the Woocommerce repository for making my development environment.
I could not find a build process in it also. Am I missing any proper step?
P.S : I don't know if I should be sharing any code samples here, but if you want anything I can share it here.
As far as I'm aware you can't do what you're trying to do and I don't believe git is meant to work that way. Having your grunt & SASS files in the master branch is the correct way of doing this, those files are also in the Woocommerce repository you've linked to.
I'm guessing what you're trying to do is create a release of a theme that doesn't have any of the 'development only files', for lack of a better term, to give to the the end user installing the theme? If so that release would be a separate 'thing' to git as git is mainly for developer version control. What I think you're after is just creating a stand-alone downloadable zip file by the sounds of things?
For example if you were to submit your theme to WordPrss.org they take it as a zip file rather than a link to a git repository.
Probably a silly question, but I cannot find any good advice on the internet so far, so hopefully you guys have some good advice. I would like to use GIT for version control and use it to deploy changes to my websites to the server(s). It's easy when I use NodeJS, but a bit more complicated when using a CMS system, to my opinion.
When I use NodeJS
When I use NodeJS it's quite easy to have a node_modules folder which contains all the external libraries which I will install on deployment. The rest(my own files) will be saved on Github and deployed to my server if changed. Obviously I will not store the node_modules folder on my Github account or send it to my server (node modules will be installed on the server, on deployment). So it's pretty easy to keep those two (third-party an my own files) seperated.
When I use Wordpress, Magento or something similar
Now it gets complicated. Mostly because CMS systems like Wordpress have a folder structure like wp_content/themes/theme_name/, so your own theme files are more or less entangled with the core structure, instead of separated like NodeJS. And it doesn't seem right to commit all my core files to my Github account as well or send all those core files to my server on every deploy (I would prefer to install them using composer or something, serverside), because I'll never touch the core files, obviously.
So is there any advice? Is there a better whey to handle this? Maybe change a configuration file with the path to my theme folder or something?
The best way to do this is to move your wp-content folder outside of your standard installation. I tend to have a folder called "wp" with the basic WordPress installation in it and a folder called "wp-content" at the same level for my content files. You can then tell WordPress that your content folder is elsewhere with the following:
define('WP_CONTENT_DIR', dirname(__FILE__) . '/content');
That goes into wp-content.php which you can also take out of the main WordPress install (and thus add to git) and place at the same level as your folders.
To make things even better consider looking at composer https://getcomposer.org/ and using that to bring in WordPress core and plugins https://wpackagist.org/ is your friend here. This guide got me started on using composer with WordPress and its a good start https://roots.io/using-composer-with-wordpress/ you can pull in your theme from git as well via composer which is great for when you deploy etc... Capistrano for example can run composer on a server :)
Hello all I'm after general opinions here.
My scenario is that when I'm building websites or web apps I tend to use grunt or gulp as a task runner. I drop in my dev dependencies via the help of bower and I'm using GIT for my version control.
In my repo I have a post-receive hook that exports repo to another folder on server that is accessible for previewing via http.
During the development phase I have all files/folders etc split into a nice MVC pattern but these can get compiled/minified into a single file with a task I have listed in my grunt file. I do this at staging/production, but for development /debugging i keep it all separated.
What's the best way to cater for the bower_components folder with GIT. I want them exported onto server but not sure that I need to be tracking them through GIT as they are maintained by their own authors.
Any thoughts or ideas would be great.
There are few opinions about adding bower_components to the git.
To keep in git:
+ "No strange issues with backend-team". I don't know why, but from time to time somebody has problems like "I just do bower install and nothing work". (I think this happens because somebody make bower install -F when others do just without -F flag)
Not to keep:
- There is no point to keep libs history. Seriously.
- Once I'm saw the issue when one guy cannot even pull from git(windows) just because somebody make bower instal jquery --save and bower instal jQuery --save (on linux). There were 2 folders (jquery and jQuery) which windows cannot resolve
I have almost finished the development of a project developed with Symfony2, and wish to put the project online.
However, I suppose there are a lot of things that need to be done so that everything works ok. I suppose, the dev mode needs to be disabled etc....What needs to be done and how?
What are the most important things to do on a Symfony2 project that will be available to everyone on the web?
I suggest you to use Capifony for deployment. It does a lot of stuff out of the box and you can make it run any custom commands you need. See its documentation for details.
Regarding the dev mode, unless you've removed the IP checks from app_dev.php, you don't have to worry about deploying it. Of course, if you wish, you can tell Capifony to delete it on deployment.
The best way to handle deployment is to create "build" script, which will:
Remove all folders and files with tests from your bundles and vendors.
Remove app_dev.php file
Make sure that app/cache and app/logs are fully writable/readable.
Packs your project into archive (rpm f.e.)
Then, before deployment, you should create tag in your project - so it will mean, that certain version of your application is released (I recommend to follow this git branching model).
Create tag.
Run your build script
Upload archive to host
Unpack
Enjoy your project
Im currently researching the same thing.
The first thing you have to consider is "how professional" you want to deploy. There are a lot of tools you can use:
Continous Integration Server ( e.g. Hudson, Jenkins)
Build Tools (e.g. Phing, Capistrano --> Capifony, Shell scripts)
Versioning Tools (e.g. Git, SVN)
I think the simplest setup is using only a Build tool and i guess you are already using some kind of versioning.
Depending on which tool you use, the setup is different, but I think there are some things you should consider with your application (maybe not all are applicable to your application)
Creating a Tag in your Versioning
Copying the new Code in an folder on production
--> if you are in a new folder you dont need to clear the cache and logs, since these shouldnt be in your versioning the first time.
loading composer (if youre using it)
installing vendors
updating database schema
install assets from your bundles
move symlink from current version to the folder of the new site
These are the things I currently need for my application for production deployment, if you deploy to an test environment you should load fixtures and run your testscripts as well.
One other option that is very well described here is to deploy the Symfony2 application with Apache Ant. Apache Ant is a Java library and command-line tool whose mission is to drive processes described in build files as targets and extension points dependent upon each other.