-1

I'm working on a small website with a handful of other coders. Most of us don't have professional experience in software development.

The website is to be run from a local server, and it has a database and python web apps. Currently, all the development happens on the server through ssh. For instance, I ssh into the server, write some code to update the database, save it, and run it.

What are some typical ways to approach this sort of project? In particular, I'm wondering about:

  • Currently we're all developing code in a shared folder on the server. Is that standard practice, or would people normally code in private user areas and transfer production-ready code to a shared space?

  • Would the coding normally be done on the host server itself? Or would it normally be done locally and then somehow transferred to the server (if so, how?)?

  • Is there a particular kind of backup system that a project like this would use?

Are there other considerations we might be missing?

Edit: I think part of the reason that writing code on the server itself seemed so appealing is because of the database. Since the database is hosted on that server, how can I try out my database-altering code locally? Is it standard to have a copy of the database on one's local computer?

If not, what's the typical alternative for evaluating database code? Is there a standard way to continuously see if each new method is working properly as I'm writing them? Is that just not normally done? Commit after every couple methods and test remotely? I think I'm just generally confused about the standard practices for this part.

closed as too broad by gnat, whatsisname, Ixrec, Adam Zuckerman, user22815 Apr 21 '16 at 20:51

Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

9

Connecting to a server using ssh coding directly on the server, while it can be beneficial at first because the changes are directly deployed, will usually prove to be bad, because if you realize you have changed a lot of code and the code does not work, you need to go through all the code again and carefully remove it.

The pretty much standard today are VCSs. There are many options, including Git, Apache Subversion, Mercurial and others. Git has been very popular lately, mainly due to its simplicity, stupidity and distribution.

I cannot speak for Apache SVN and Mercurial, considering I have little to no experience using them.

With Git, you usually have one bare repository and unlimited amount of working repositories (usually local copies). When you clone a project from a bare repository to your own PC, you don't only copy the files but you copy the history as well. Meaning as long as your local project is up to date, if your main server containing the bare repository ever died, you can take the local repository you have, push it to a new server and you will be where you were before.

The workflow with git specifically is usually done like this:

  1. a bare repository is created on a server (usually containing master branch representing the latest production-ready application version)
  2. developer pulls the repository to his local machine
  3. (optional) developer creates a branch to isolate his changes from the global branch/namespace (if he creates a branch, until he pushes it to the bare repository, the branch will be only available to him, locally)
  4. developer makes changes to the project (local work)
  5. developer makes sure the changes work (local work)
  6. developer commits the changes and pushes them to the branch he is working on (affects the bare repository on the server)
  7. (optional) should the developer work on a custom branch he created, he will merge this custom branch to branch used for building either directly or using a merge request/pull request

With Git, all the changes to the code are performed locally, none on the server directly. After the changes are completed and working, then the local code is taken and merged to the production version of your application.

With branching and Git you have the great option to undo large code changes very quickly, such as you very coding a feature which should be only available during a part of the year, like Christmas. Before Christmas you coded it, during christmas you deployed it, and after christmas, you can simply undo a commit responsible for the addition of the christmas bundle to the main project and it will be removed.

For the code itself, considering git is distributed, all your peers working on the project will have a complete copy of the project including history on their local machines, you don't really need a sophisticated backup system anymore. Unless your, the server and all your peers' machines died at the same time, you will always have a source to pull the project from, be it your local machine or one of your peers'.

Databases are usually not versioned, so if you do not want to lose your data, they should be backed up regularly. The first step is RAID configuration, mirroring the disk with database to a second one. An option is master/slave replication, which represents backing up in a slightly more complicated manner (as long as the slaves are up to date with master).


To answer the questions shortly...

Currently we're all developing code in a shared folder on the server. Is that standard practice, or would people normally code in private user areas and transfer production-ready code to a shared space?

Not a good idea. Try to get hand on a VCS and use that one instead. Editing files directly on the server may be a good idea for tiny changes to code, not so much for development.

Would the coding normally be done on the host server itself? Or would it normally be done locally and then somehow transferred to the server (if so, how?)?

Locally is defenitely a better idea. You can test the changes on your local machine without directly affecting the server and its code.

Is there a particular kind of backup system that a project like this would use?

If you use Git, there you won't really need to backup the project itself. You will still need to find a way how to backup a database, possibly using some RAID.

Are there other considerations we might be missing?

Continuous integration comes in mind. Where I work we use Jenkins. It's a tool to automate the process of deploying your application to the production server. During it Jenkins can perform specific tasks such as running unit/integration tests.

You will need to configure at first, but once that is done and it is linked to your repository, you can easily build it from a selected branch and it will do all the checks that need to be done (according to your configuration) and if the checks pass deploy the code to your production machine.

I think part of the reason that writing code on the server itself seemed so appealing is because of the database. Since the database is hosted on that server, how can I try out my database-altering code locally? Is it standard to have a copy of the database on one's local computer?

If not, what's the typical alternative for evaluating database code? Is there a standard way to continuously see if each new method is working properly as I'm writing them? Is that just not normally done? Commit after every couple methods and test remotely? I think I'm just generally confused about the standard practices for this part.

If you have only one version of the database right now, you really should make a backup to your local machine or a development server and when you develop, use this copy instead.

You should not be testing changes to the code on the production database, that's a really bad idea. What if you change a removal procedure, run it and during the run realize it does not do what it is supposed to do and thousands of records are suddenly marked as deprecated or worse, completely removed.

If they are marked as deprecated, good luck fixing your database for the next 7 days, if they are removed, you can probably pretty much close the shop.

Generally speaking, you want only production-ready code on your production server. Production-ready code, which is tested that works. Nothing else. Do all your work locally, test it on a dummy database, where you can insert/update/delete whatever you want, and once you are sure the code works, then deploy it to the production server, not before.

  • That's really helpful - thank you. After thinking about your answer I added a new question too. – Hatshepsut Apr 15 '16 at 7:21
  • May i add that in my company we have a sandbox repository where developers develop software with fake data, a first level test repository where developer test the system with fake data, a trial repository where a small amount of clients test the system with real data and the production repository where the system is finally used by the client's organization. More the deploy is near to the final repository more anxiety we get. – JoulinRouge Apr 15 '16 at 7:35
  • @Hatshepsut Added information, an answer if you wish, to the two paragraphs you added. – Andy Apr 15 '16 at 7:40
  • 1
    @JoulinRouge I don't know what kind of VCS you are using, but in Git, that's what branches are for. You can have master, preview and development branches representing the three states you described, using that it is also easier to transfer the code from one stage (branch) to another. – Andy Apr 15 '16 at 7:45
  • 1
    @DavidPacker it's salesforce , you don't have actual repositories or branch since it's cloud (resources.docs.salesforce.com/200/latest/en-us/sfdc/pdf/…) i was just pointing out that the "best practices" are budget and project size dependent. – JoulinRouge Apr 15 '16 at 8:07

Not the answer you're looking for? Browse other questions tagged or ask your own question.