linux directory location best practices for software development - directory

I am new to linux (ubuntu) and am tasked to develop web pages using vscode. What would be the ideal location for me to keep my project directories? I don't want to be illogical or pollute a file system convention I don't know about.

Personal projects all belong in the /home/ directory. When you're ready to test you'll symlink to the directroy you host from. When you're done with the project you'll have to decide where the best "permanent" location is. See the File System Hierarchy Standard for details.

You can automount external drive and use that drive to save your projects.

Related

Use Git in SSH to pull specific directories

Total newbie question but what is the best practice when it comes to using SSH with Git? I'm working on a WordPress project. In the root I have gulp and other dev files/folders like SASS and Scripts that I don't need on the server and in the same project I have my WordPress folder that contains a theme and a few custom plugins. As you can imagine when the theme or any of the plugins are ready to be deployed I don't want to pull everything in my repository on the server. So far as a newbie I've always just pull and pushed the entire repository and used FTP to upload what I need to the server, so how is this done with SSH and Git and is there a better way to have my setup?
EDIT: To make my question a little bit more clear let me give you an example of what I think my issue is. In my main project folder, I have a SASS folder next to my WordPress folder. All I really need to deploy to the server is the WordPress folder. My build process that happens on my dev machine combines all of the SASS files into a single CSS that is then placed into the WordPress folder. I need the SASS folder to be tracked by Git so that any other developer can pull them and continue developing so I can't have git ignore it. However none of those SASS files need to be on the server for WordPress to work either. I just simply need to deploy the WordPress folder and everything that's in it.
I understand the idea of creating a bare repository on the server and using post-receive hook to point the git folder sitting outside your web root to point to where the web root is. But that's basically how GIT and SSH work and that's not answering my concern.
Not with Git
Git is not designed to pull specific files or directories only. It's a directed acyclic graph with binary blobs as objects and sometimes multiple objects get compacted into a single larger object.
Due to Git design, your specific request is not possible.
Alternatives
post-receive hook
If your website only contains simple static files then it's okay to push to a git repository over SSH. In reality, it's unlikely your repository will be large as long as you don't have non-text files.
Take for example the following setup.
/var/lib/www - apache web dir which is the cloned copy of www.git
/var/lib/www.git - a bare git repository.
/var/lib/www.git/hooks/post-recieve - A server side git hook. It can be a shell script that pulls the www repository when this repository is updated.
Sample post-recieve hook script:
#!/bin/bash
cd /home/sam/sandbox/git-hooks/www
unset GIT_DIR
git fetch origin master
git reset --hard origin/master
Zip up build in a tar.gz
At the end of your build you can zip up your files in a tar.gz. This file should be hosted somewhere (perhaps GitHub releases if you're using GitHub). Some enterprises use on premise artifact hosting like Nexus or Artifactory.
The idea being: you have a tested artifact that has a specific sha256sum. The artifact you test is the exact same artifact which eventually goes to production.
Diving into more detail such as continuous integration, continuous delivery, and the software development life cycle might be out of scope for your question.
No best practice.
Git is for source control, not for deployment. There is no best practice for using git this way because git is not a deployment tool. You also don't need git history on your server. In fact, you don't need git at all unless you insist on using it for deployment. You are welcome to use it this way but it's not ideal because of exactly the kind of problem you're asking about.
What is the best practice?
There are a number of tools you could use to handle your deployments. Most of the tools generally let you set up a series of steps that let you deploy the code you want into the environment you want. You could go with simple tools such as Phing or Deployer in the PHP world, or something more sophisticated like Puppet or Chef if you have more complex needs. You could just write your own bash scripts if what you need is really very simple. I recommend Phing or Deployer given the info you've provided. https://deployer.org/ https://www.phing.info/
You'll just configure whichever tool you want to ssh into your target box and copy over only the files you want into the directory you want on the server, in whatever way you would like to do that. Usually, you have the script copy files into a temp dir, tarball them up, ssh them over and untar them. After that, you'll usually do some additional work on the server to move files around, change symlinks, whatever else you might need to do.
What about compiled SASS, ES6 js files, or modern static stuff?
All you need to do is add steps to the handle the static files and where you want them to go. Include the generated static files in your tarball when you push stuff up, and put them in the right directories in the server once you untar it.
When you configured your SASS compiler, and whatever other pre-compiled static code you may have - you configured it to create a destination file. That is, the file(s) of actual CSS and JS that they generate. That's all you need to bring along - and if you have the destination directory set to be inside your wordpress theme, you may not even have to pay all that much special attention to it's handling. You may need to move them somewhere else once they are on the server but that all depends on the specific setup in your server, which I think is outside the scope of this question.
Additional Notes:
You didn't ask about this but I thought it was worth mentioning, that you shouldn't be sending the entire wordpress repository every time you update. Just like you don't need the uncompiled SASS code, you also don't need to be repackaging core WordPress. You don't even need to be commiting core WordPress, its a dependency and you don't need to be changing it.
All that should be getting committed by you is your theme and plugin code, and the uncompiled static files. Compiled static files and external dependencies like the WordPress core don't belong in your git history. For deployment purposes, WordPress should already be installed. The stuff in your tarballs should just be plugins and themes, and additional static files if they aren't already in there for some reason.
TLDR;
Don't use git for this. Use a tool like Phing or Deployer. Build your static files into your theme, and create phing/deployer scripts that tarball up only the code you want, SSH's it over to your server, and untars it into the directories you want. If you have some special location on the server for your static files, just make sure to add steps in your script for that.
So, based on your question and comment, there are three computers involved. There is a web server (when you say "server", I take it as a Web server in this scenario, or the server computer that runs a Web server program). There is another server where your git repo is hosted. And, there is your dev workstation. Is this correct?
It seems like, you have a cloned git repo on your Web server. Your current practice/workflow appears to be (1) (based on your expression "SSH'ed into my server") you log into the web server via SSH (just like Telnet) from your workstation (SSH is just a protocol, which can be used for different purposes). (2) you pull from your repo on hosted service (e.g., github), and (3) deploy it to your "www" directory on the same server. Is this correct?
(I can think of an alternative scenario based on your use of the word "FTP", etc., but let's focus on the above scenario, for now.)
Now, your question is, whenever you "pull" (on your Web server), you feel like you are pulling everything from your repo on your hosted service. And, is there a better way? Am I understanding your question correctly?
If so, as another commenter suggested, git (and, any version control system, in general) is very good at fetching "deltas" only. If you are worried about "fetching everything" every time you pull (the step (2) above), then your worry is unfounded.
Now, the question is, why do you have a git repo on your Web server, if that is indeed the case? This is a pretty legit setup and I've done this before (e.g., on EC2). But, as a best practice, people generally don't do that on "production" servers. It's because you have to "build" your web app, and you really don't want to do that on production servers.
The next question is, what do you exactly do in Step (3)? The build process (whatever process you use) typically generates an "output" which can be directly deployed to the web server. (The convention is the output is generally a single folder, "public", "www", "dist", or whatever, or a single file (e.g., tar.gz, zip, jar, war), etc.) Regardless of whether you build the deployable output on your dev workstation (or, a build machine) or on your Web server, you don't generally do "deltas" in this context. Even if you've only changed a single file (say, a CSS file), you generally build the whole output again (instead of, say, just replacing the changed CSS file only). When you use FTP to upload files, etc., you can selectively upload certain files and/or directories, etc., but as a general practice, we don't do that. We always build the complete output from scratch and deploy it to the Web server. (This is mainly to reduce the potential deployment errors and increase the reliability.)
So, to answer your question, (A) If you are pulling git repo on your Web server, you should really change that practice, and move the build process to your dev computer or a dedicated build machine. (BTW, services like github, gitlab, TFS, ... provide the build service for you.) (B) If you are currently selectively FTP'ing your web app files to your Web server, then you should really consider adopting some kind of formal build, and deployment, process moving forward.
After your SASS build process is done use scp or rsync to move the files to the prod server:
scp -r /[local wordpress dir]/wp-content/themes/your-theme/ username#your.prod.server.com:/path/to/dir/wordpress/wp-content/themes/
scp -r /[local wordpress dir]/wp-content/plugins/* username#your.prod.server.com:/path/to/dir/wordpress/wp-content/plugins/
I am working in a project and using git ssh with bitbucket following is the process i am using it may work for you also if not please correct me :
Step 1 ->I have setup git and create repo in bit-bucket.
Step 2 ->And setup project with my local and linked with my repo.
Step 3 ->connect my server using ssh.
Step 4 ->Work in my local and commit and push all changes in my git repo.
Step 5 ->Run git pull on ssh so all changes deployed in my server.
I am using above process and i love this process.i have used .gitignore file that is not required for push on my repo.
Thanks

Using rsync to deploy code updates for Symfony application

I have a couple of development machines that I code my changes on and one production server where I have deployed my Symfony application. Currently my deployment process is tedious and consists of the following workflow:
Determine the files changed in the last commit:
svn log -v -r HEAD
FTP those files to the server as the regular user
As root manually copy those files to their destination and, if required because the file is new, change the owner to the apache user
The local user does not have access to the apache directories which is why I must use root. I'm always worried that something will go wrong either due to a forgotten file during the FTP or the copy to the apache src directory.
I was thinking that instead I should FTP the entire Symfony app/ and src/ directories along with composer.json to the server as the regular user then come up with a script using rsync to sync all of the files.
New workflow would be:
FTP app/ src/ composer.json to the server in the local user's project directory
Run the sync script to sync the files
clear the cache
Is this a good solution or is there something better for Symfony projects?
This question is similar and gives an example of the rsync, but the pros and cons of this method are not discussed. Ideally I'd like to get the method that is the most reliable and easy to setup preferably without the need to install new software.
Basically every automated solution would be better than rsync or ftp. There are multiple things to do as you have mentioned: copy files, clear cache, run migrations, generate assets, list goes on.
Here you will find list of potential solutions.
http://symfony.com/doc/current/cookbook/deployment/tools.html#using-build-scripts-and-other-tools
From my experience with symfony I can recommend capifony, it takes a while to understand it, but it pays off

How to copy IIS 7.0 website to local computer running IIS 8.0

i want to copy contents, code, build files and configuration files from a IIS(7.0) server which is running a live file and copy everything
to another machine which got IIS 8 installed.
the destination computer has other web sites installed, so i dont want to disturb configuration for those sites.
do i first copy the code from the source and create a folder on destination and copy the files there and than follow with the configuration settings?
Probably meant for serverfault...but here goes..
Review/inventory current application. e.g.
"config files" for any explicit settings that may have to do with paths, connections (db), certificates (ssl), and/or expected depedencies (assemblies, framework version/s, other web applications, etc.)
hopefully the application is documented and/or original developers are handy to assist in this inventory process
the point is to first "know" what you're moving before doing anything, this would be the most important step..the rest is more or less config....
create folder in target machine
doesn't have to be in C:\inetpub\wwwroot, but you'll have to modify permissions as necessary.
also if there's an existing app in wwwroot, possible headaches can arise with settings inheritance
copy files from source -> target
IIS Manager -> set up the new "web site"/"Application" as necessary (AppPool, etc.)
Test, test, test
Fallback plan (if all goes to hell, need to "revert")
Applicable network stuff - DNS, etc. (the moment of truth)
Coffee. Lots. Pray you don't have to go to #6 :)
Hth...

Drupal & NFS Directory

I have 2 parallel Drupal Web Servers running (serving for one Drupal Instance together) and now i need to install NFS. My experience in multi Drupal Servers is, each Drupal Instance (Server) uses their own Aggregated JS + CSS files (storing in: sites/default/files/js and sites/default/files/css folders) which can NOT be used as common. (Files can not be the same for both Servers. They use their own ones.)
Based on these issues, my questions are:
How NFS actually works between Multi Drupal Servers?
Which directories will be/need to be shared between?
What will happen to Aggregated Files?
What will happen to Web User Uploads paths and files? (Need any configuration in Drupal?)
Can anyone share these knowledge/experience please?
You can definitively work with NFS and Drupal.
I do not understand why you do not want to share the files directory between both.
In fact you have two solutions:
1) Share all the source tree, starting at the web directory root, or even earlier if you have external directories for private files
2) Share only the moving directories and have all code based synchronised before and aftter any upgrade via some rsync commands. In this case you need to share between servers:
the files directories (project/www/site/default/files, project/www/site//files)
the private files directories (project/private) <-- it's an example
the php temporary upload path (project/tmp for example), check that both servers use the right folder (it's a php setting) and that this folder is shared.
before Drupal7 I would use solution 1, now the number of internal filesystem tree traversal launched by Drupal on a lot of occasion make it very bad on slow filesystem (and NFS is usually quite slow). Using APC with all filesystem check disabled (apc.stat, stat.ctime, etc) does not prevent Drupal from trying to access every file on your filesystem on a lot of occasions. So solution 2 is to be prefered.
I did not experience any problems with file aggregation with such installations.

Deploy ASP.Net website from SVN to multiple server?

I need to deploy a website from the SVN to different servers all within our own network. The code is currently not compiled but probably will be in the future.
First, the site would need to be deployed to the development server for the developers to test.
Once the Developer signs off, it would be deployed to the staging server for the testers.
Once final sign off was given it would be deployed to a server farm- two live servers.
Each server has a couple of settings in the web.config to that are different (except the two live servers, of course). I would like to use templates, the way the Ruby on Rails world does. It seems like an elegant solution to multiple web.config files.
I also need to create a list/report of the files that were changed and what the change was since the last deployment.
I am thinking of writing a script that will do the following:
1. Take args for server to deploy to, and revision
2. Export a copy of the source to a directory with svn export -r <deploy revision>
3. Delete the web.config file
4. Use ttree (a template tool http://template-toolkit.org/) to create the correct web.config
5. Create a list of file changes with svn list -r <deploy revision>:<current server revision>
6. Store the <current server revision> of the website for when the script is run next time
The problem I have is it doesn't seem like the most elegant solution. It could become unmaintainable, and I prefer to use tools that are already available rather than re-invent the wheel. Unfortunately I don't think MSDeploy will do what I need, but I'm happy to use it, or anything else, if it will do what I need it to. Does anyone know of any tools that are up to the task or is the script my only option?
Check out TeamCity. I have my build server setup so that it can deploy to different environments with different settings based on the build configuration all in "One Click". It's relatively painless to setup and integrates directly with Subversion and other source control systems. This would be a more elegant solution to the issue you are dealing with...

Resources