I have a wordpress site. The Goal is to create a web app and some how merge the code into the existing wordpress code base and provide developers access to the GIT and push their changes to the code base. I'm not sure the steps involved in achieving this goal but would appreciate any people who have experience in this.
I'm sure there is a much easier way to do this - but I have tried downloading the WP Theme from my hosting cPanel. Then upload that folder to git hub. Does anyone have experience with Git Integrations for bluehost?
So basically, I have Node.js application locally (WebStorm project) and constantly pushing changes to git. I would like to create one-click desployment solution executable from my WebStorm project what will:
Clone/Pull project from git
Install dependencies
Edit config (database connection, etc...)
Based on config make sure database is ready and if not initialize new one
I achieved parts 1 and 2 by using pm2 deployment function. If I run command, everything is updated from git and dependencies are installed.
Part 3 is problem, because I do not want to push production config into git (even it is private repo) and I have only example config in git repo. I was thinking about script what will copy example config and then prompt me somehow to edit it, but I am not sure now to achieve this without connecting manually into production server and second problem is I need to copy new example config every new version, because there might be changes in config structure between versions.
Any suggestions how to achieve this easily and without need to log into production server manually?
Part 4 is nice to have feature if anyone have suggestions how to achieve this, too.
I am new to the world of grunt but I feel like there must be a way to do this. Hopefully I can explain my issue in a way that makes sense so you can be of assistance.
Essentially, I have a git project, including a gruntfile, that I use to start all new websites. I clone the project, delete the .git folder and setup a new project in bitbucket for it. Over time I have had to make some modifications to the gruntfile and it is annoying to go back to an old project where I hadn't made those modifications. Is there a recommended way to ensure that my template is up to date on all of my projects?
Things to note:
1) I am familiar with grunt scaffolding but I have never used it, is this the use case for it?
2) my projects live in bitbucket and are private. My initial solution to this problem was to use grunt curl and pull the latest and overwrite the previous gruntfile
3) The issue with #2 is that I would need to put my username/password in the path and can't figure out how to prompt the user, even if I do and they enter the login incorrectly bitbucket still returns something (a bad login page) and this would overwrite my gruntfile.
Thanks in advance! I appreciate anyones input
I assume you are using git with bitbucket. If that is the case you can do a pull from a master repo that contains your template grunt file in each of your project repositories for the desired effect.
See this answer for how to pull from a remote repo.
remote repo q
Since you only care about merging in changes from the Gruntfile.js you can pull it specifically from the remote template repo. I'd suggest following this pattern assuming you add the remote reference to you template repo when necessary:
From you project repo create a new branch
Pull the Gruntfile.js from the template repo
Resolve any merge conflicts
Merge with master
See the last answer on this question for how to pull a single file:
fetch a single file
I have been going through documentation and such and have SVN working, but I want to put it on an existing directory. I imported that directory, so do I rename/delete the non SVN directory and then checkout the SVN to the non SVN directory location? I am just trying to understand how to get it to start posting to our website URL.
If so, is there any way to keep the current non SVN and make it SVN rather than import and overwrite?
Thanks, I am trying to understand SVN, but find a lot of the tutorials and such on the web to be confusing.
Yes, you have it exactly. Once your code has been added to the repository, you can get rid of or rename your original code directory. Then checkout the project from the repository into the same location as your previous code and continue working from there.
UPDATE
To make it so that your website is updated from the repository, you actually need two working directories, and a repository.
Repository: The repository stores the code and changesets, but isn't directly accessible as a file system. Keep a backup!.
Working directory 1: You develop and test your code from a working directory checked out from the repository. Commit changes back to the repository.
Working directory 2: Rename the code directory on your webserver. Checkout a copy of the code to your web server in its place. Technically it is now a working directory, since it contains the .svn metadata directories, though you won't usually make changes here.
Make changes to your code from your development working directory (1) and commit them back to the repository. When you are satisfied that they are working correctly and have been properly tested, on the web server's code copy (2) do svn update (or if you're using Tortoise SVN on the web server, do an update). This will synchronize the server code with the current development version.
Subversion will not automatically push updates to your web server. You will need to pull them in with an update when you need to. It is possible to use what's called a "post-commit hook" to cause Subversion to execute a script when commits are made, and that script could update or export code to your production web server. However, you would need to write the script and it's kind of an advanced usage of Subversion. I would recommend trying out the method I described with a working copy on the web server to get accustomed to the workflow befrore trying anything more complicated.
Addendum If you really want to do this (and I don't really recommend it unless you really test well) a very easy method would be to schedule a cron job that does svn update every couple of hours (or minutes) on your production site.
Don't forget that if you do happen to modify your code directly on the web server, you must commit it back to the repository from there, and do an update on your development working copy.
This is somewhat related to my security question here. Is it a bad idea to use an hg / mercurial repository for a live website? If so, why?
Furthermore, we have dev, test and production installations of our website, like dev.example.com, test.example.com and www.example.com. If it's a bad idea to use a repository for a live/production website, would it be OK to use an hg repository for the dev and test sites?
I'm also concerned about ease of deployment. We have technical and less technical co-workers who will be working with the site. The technical people (software engineers) won't have any problem working with the command line or TortoiseHG. I'm more concerned about the less technical people (web designers). They won't be comfortable working on the command line, and may even find TortoiseHG daunting. These co-workers mostly upload .css files and images to the server. I'd like for these files (at least the .css files) to be under version control, but I want this to be as transparent as possible for the non technical team members.
What's the best way to achieve this?
Edit:
Our 'site' is actually a multi-site CMS setup with a main repository and several subrepositories. Mock-up of the repository structure:
/root [main repository containing core files and subrepositories]
/modules [modules subrepository]
/sites/global [subrepository for global .css and .php files]
/sites/site1 [site1 subrepository]
...
/sites/siteN [siteN subrepository]
Software engineers would work in the root, modules and sites/global repositories. Less technical people (web designers) would work only in the site1 ... siteN subrepositories.
Yes, it is a bad idea.
Do not have your repository as your website. It means that things checked in, but unworking, will immediately be available. And it means that accidental checkins (it happens) will be reflected live as well (i.e. documents that don't belong there, etc).
I actually address this "concept" however (source control as deployment) with a tool I've written (a few other companies are addressing this topic now, as well, so you'll see it more). Mine is for SVN (at the moment) so it's not particularly relevant; I mention it only to show that I've considered this previously (not on a Repository though; a working copy, in that scenario the answer is the same: better to have a non-versioned "free" are as the website directory, and automate (via user action) the copying of the 'versioned' data to that directory).
Many folks keep their sites in repositories, and so long as you don't have people live-editing the live-site you're fine. Have a staging/dev area where your non-revision control folks make their changes and then have someone more RCS-friendly do the commit-pull-merge-push cycle periodically.
So long as it's the conscious action of a judging human doing the staging-area -> production-repo push you're fine. You can even put a hook into the production clone that automatically does a 'hg update' of the working directory within that production clone, so that 'push' is all it takes to deploy.
That said, I think you're underestimating either your web team or tortoiseHg; they can get this.
me personally (i'm a team of 1) and i quite like the idea of using src control as a live website. more so with hg, then with svn.
the way i see it, you can load an entire site, (add/remove files) with a single cmd
much easier then ftp/ssh this, delete that etc
if you are using apache (and probably iis as well) you can make a simple .htaccess file that will block all .hg files (or .svn if you are using svn)
my preferred structure is
development site is on local machine running directly out of a repository (no security is really required here, do what you like commit as required)
staging/test machine is a separate box or vm running a recent copy of the live database
(i have a script to push committed changes to staging server and run tests)
live machine
(open ssh connection, push changes to live server, test again, can all be scripted reasonably easily, google for examples)
because of push/pull nature of hg, it means you can commit changes and test without the danger of pushing a broken build to the live website. like you say in your comments, only specific people should have permission to push a version to the live site. (if it fails, you should easily be able to revert to the previous version, via src control)
Why not have a repo also be an active web server (for dev or test/QA environment anyway)?
Here's what I am trying to implement:
Developers have local test environments in which they can build and test their code
Developers make a clone of the dev environment on their local dev machine
Developers commit as often as they want to their local repo
When chunk of work is done and tested, then developer pushes working change sets to dev repo
Changes would be merged and tested on Dev, then pushed to Test/QA, and so on.
BTW, we're using Mercurial. I believe this model would only work using a distributed source code management tool.