I started my first job as a dev about 3 months ago, at a very small company where I’m (currently) the only developer, and I’ve been setting them up with git. Their codebase is a bit all over the place, but mainly split up into three different sections.
1.) In the root directory of a web server, located on a Windows server, that I have direct access to.
2.) In a separate directory on the same Windows server, outside of the web server’s root directory.
3.) Hosted server that we access via FTP.
I’ve set up git for the first two sections in the same way – I have a bare repo initialized parallel to the live code, with a post-receive hook that deploys to the production directories. My personal “local” repo is also parallel to the production directories, with the same name, just with my name in front of it.
So for example, it would look like this:
production_folder/
production_folder.git/
<my_name>_production_folder/
This has been working alright, but the more I use it the more it doesn’t exactly seem ideal. For starters, I have to keep a close eye on the path names, because the ones in my “local” repo of course reference <my_name>_production_folder and the ones in production need to reference production_folder.
So my question is, is this method generally ill-advised? And if so, would it be better to have my local repo on a totally different drive altogether somewhere, so that all the file names and file paths would be identical? Are there other reasons to/to not do it this way?
I know how to use the basics of git already, and the things I find when searching for an answer about this are more along the lines of “learn how to use this particular part of git” rather than best practices for repo placement. this question was similar, but concerns putting development repos within
the production code directory, which I’m not trying to do. I also went through the questions links that the answerer posted and didn’t quite find what I’m looking for.
Thanks in advance, and any guidance/advice/resources are greatly appreciated!
9
Too often I see people use version control as a tool to deploy the application. Unfortunately, it appears you have fallen into this trap as well.
Git is good a tracking changes to files. Git is a poor choice for a deployment tool, especially if file paths within your repository are named according to an application environment. The one exception for this is configuration files. Config files frequently contain an environment name, e.g. Web.dev.config, Web.test.config, Web.prod.config, etc.
Otherwise, all files and folders should be named according to their use within the application and without regard to which application environment they are used in, or where the file is stored on the server. This is the first thing you should fix.
This leads to the second major task. You need a proper tool to deploy the application. Do not feel like you need to sign up for Azure DevOps, Jira, or download, install and configure a Jenkins build server. A shell script can be a perfectly good deployment tool1. As an added bonus, store the shell script in your Git repository so you can track changes to it.
Basically:
- Git is not a good tool for deploying an application.
- Source code files and folders should not be given environment-specific or server-specific names
- The one exception to this rule would be config files, where it makes sense to know which environment the config file pertains to.
- Use a separate tool for deploying the application, like a shell script.
- Store the deployment scripts in your Git repository.
- I’ve found most problems in life can be solved with “more bungie cords” or “write a shell script.”
6