-1

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!

confused_nomad
  • 19
  • 1

1 Answers1

6

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.
  1. I've found most problems in life can be solved with "more bungie cords" or "write a shell script."
Greg Burghardt
  • 34,276
  • 8
  • 63
  • 114
  • This is some great information, thank you. I do have a couple of follow up questions, that may sound a bit noobish. First, why is it not a good idea to deploy with git? I can see how my need to name things differently due to them being on the same server is an issue, but what if my local repo and production repos were on completely separate drives with no chance of naming conflicts? Would there still be issues? – confused_nomad Sep 08 '22 at 15:09
  • Second question here for clarity. Due to being self-taught, I'm a bit fuzzy on what you mean by 'deploy the application.' Does this simply mean somehow pushing updates to your live code, or is there some other containment process here that I'm missing? (And I don't mean containers like Docker or anything like that) – confused_nomad Sep 08 '22 at 15:10
  • @confused_nomad: deploying typically means moving the files to the servers, applying configuration changes, and perhaps even data updates. This could also include making a backup copy of files, if necessary. Basically all the steps it takes to put updated application code out on to the servers. As for why Git is not good for deployments? That is situational. You can "git pull" from the servers, but that assumes you only need app code changes. As soon as your deployments need more than that, Git becomes useless. – Greg Burghardt Sep 08 '22 at 15:40
  • I just realized something and don't know why I didn't mention it earlier, but the post-receive hook in the bare repo *is* a shell script. Does this still go against the steps you were recommending? – confused_nomad Sep 08 '22 at 18:51
  • @confused_nomad: it still executes as part of your version control workflow. This couples version control to deployment, and yes, it go against the steps I am recommending. – Greg Burghardt Sep 08 '22 at 19:40