DevelopmentVMHowto

From SoylentNews
Jump to navigation Jump to search

Development - parent

Download and Install VM

The Dev VM can be downloaded from http://vm.soylentnews.org/Slashdev_14.10.ova. This is the latest Slashdev vm and has many enhancements over the original version. It is a vm that is designed to run on VirtualBox. Information and downloads of VirtualBox are available here: https://www.virtualbox.org.

Once you get the VM downloaded and the VirtualBox up and ruining, you will want to do a File:Import Appliance in VirtualBox. This will unpack the VM into you environment. Start up the VM and log in with the username and password of slash.

The VM has port forwarding setup to you local system for ssh and http.

ssh: 8022
http; 1337

For ssh your connection string should be:

ssh slash@127.0.0.1 -p 8022

For websites, apache will use the name localhost instead of 127.0.0.1 so you will need to use:

http://localhost:1337

Setup the Environment

The slash user home directory is in /srv/slashdev/. The slashcode GitHub repository is located in slashcode. This is where you will make changes to the code you want to test. The actual slashcode install is located in slash.

The first thing you should probably do is update the repo to the latest version.

cd ~/slashcode
git pull

Now we need to install the new code to slash. Here is a script that will help with that. Create a new file called deployslash.sh in the slash home directory and chmod it to 755.

There are a couple of scripts set up in the vm that make deploying and reloading slashcode easy. The first script is deployslash.sh and the second is reloadslash.sh. These scripts are in the shash user's home directory. The deployslash.sh script will cd into the slashcode directory and install the slashcode to the appropriate locations and then stop the slash daemon, stop and start Apache, clear the memcache, and finally restart the slash daemon. The reloadslash.sh script does the last steps only and is generally needed when updating templates, vars, and other items within the admin interface of the slash site. Most changes will not take effect right away due to caching. The reload will empty the caches and unload any running Perl scripts from memory.

MySQL Updates

We need to update the dev environment to work with the new slashcode. The update files are normally in /srv/slashdev/slashcode/sql/mysql/. The upgrades file has the latest updates since that last major version of slashcode. The 14.10 version of the vm is fully up-to-date with with the 14.10 release of the slashcode, so no updates to MySQL are needed. You will need to add any future DB updates that are listed in the upgrades file to keep the new code working properly.

MySQL is accessed with root as the user and the database slashdev. To access the DB use the command:

mysql -u root slashdev

Update Slash

Now lets update slash to our new code by running:

deployslash.sh

Making Your Own Changes

To do simple updates, you would make changes to the files in slashcode and redeploy using the deployslash.sh script.

What if you want to develop code and have it merged into the main repo? In this case you will need to setup your own copy of the repo do do your development work. First if you do not have your own account on GitHub please set one up. Next go to the slashcode site https://github.com/SoylentNews/slashcode and click on Fork in the upper right. Fork the repo to your user account.

Now on the VM go to slashcode. We will setup your copy of the repo as a remote. Run the commands:

git remote add {name} {url-to-your-GitHub-repo}
git fetch {name}
git checkout {name}/master

Redeploy slash and you are working from your own repo. As you may have noticed the primary work is being done on the master branch. You will not need to worry about the other branches of the code for now.

Once you get code you like, and have it committed to your personal fork, you can do a Pull Request, https://help.github.com/articles/using-pull-requests, that will create a ticket for the SoylentNews/slashcode repo to merge your commits to the master branch. After proper testing by the Dev team and other sanity checks, you code will be merged and eventually put on to the production servers. See GitUse for more info about using git.


Just a note: I am new to git, so the above directions are what I have been using. If people have a better method for doing this please feel free to update this page with the new information --pauulej72.