So I was looking at the Getting Started with Django http://gettingstartedwithdjango.com/ tutorial, and everything was done in a vm. The author set up a vm, and then created a virtualenv in the vm. Is this good practice to get started on a django project, or software projects in general? Why the need for a vm? What happens if I have more than one project - should I use two vms? Or just create additional virtualenvs in the original vm?
I'm still a student in school, and I'm working on my own personal side projects, so it'd be useful to get some input on how things are really done in the real world.
Thanks!
You do not need VMs. You can get through just fine using virtualenv with an environment for each project - especially just starting out in Django.
In the future, one of the times you may need a separate VM environment for your project is if it has a lot of unique infrastructure needs. It's much easier to setup a VM, setup the unique environment, and not have to alter it when you want to work on other projects.
Another common reason I see people using VMs is when they have a Windows machine but want to develop in Linux. It's easy to spin up a Linux VM and work there since Linux is more programmer friendly.
It's subjective. I leverage virtualenv and virtualenvwrapper for my development, which I do on Linux. There are instance where you might need to leverage two separate VMs...it just depends, although I haven't encountered this.
There's no unwritten rule that says you have to use a VM. Python (and many other languages/frameworks) simply work better on Linux, so many people will leverage VMs to run Linux on Windows or Mac to do their development in that environment.
Related
I am going to create environments. For now i have gcp machine and i run jupyter in there. Everytime, i need start it, and with 3 people it is hard to work in same environment. I know, there is docker, jupyter hub, but did not find and suitable roadmap to create dev/prod environment.
My aim to create dev and production environment. Everything should be on GCP.
Any suggested path ?
Thanks
You can take a look at the best practices for enterprise organizations. In order to properly split resources it's often advised to use different projects. However, depending on the GCP product, you could also use versions, such as with App Engine (see this StackOverflow thread).
I'm new to git. I've read the well-written intro book. But gee, it's still not a trivial topic. I've been bumbling around, experiencing various problems. I realized it might be because I'm unaware of workflow, and specifically, "what are the best practices for doing what I'm trying to do?"
I started out developing a django project on my win7 with Pycharm. Great way to get the initial 95% written.
But then I need to deploy it to my production machine at PythonAnywhere.
So I created a private Github repository, pushed my win7 codebase to github.
Then in pythonAnywhere, I cloned the github repository.
For now, no others work on this project. It will not be released to the public.
Now that the server is running on PythonAnywhere, I still need to tweak settings, which is best done on the PythonAnywhere codebase side. But there are other improvements (new pages, or views) that I'd rather do inside Pycharm IDE on my win7 than in vim on python anywhere.
So I've been kind of clumsily pushing and fetching these changes. It's been kind of ham-handed, and I've managed to lose some minor changes through ignorance.
So I'm wondering if anyone can point to a relatively simple workflow that would handle the various tasks I mentioned:
1) improving functionality of the site (best done in Pycharm IDE)
2) production server issues and tweaks (best done on PythonAnywhere)
3) keeping everythign safely backed-up on Github
The other issue is that I have another django app that I want to build. It's easiest to temporarily hang it off the django project I've already built. But I'd prefer to keep it in its own repository.
So I have Original_Project, Original_App stored in Original_Repository
I want to make new_app, and have it, for the time being, run in Original_Project, but I want to version control it in New_Repository.
I think/hope that I could put a .gitignore in the Original_Repository, saying ignore the new_app/ Then I git init new_app/ as its own repository. Is that sound or mad?
You should avoid editing your code on the production server as much as possible, and never commit from the production server. If you end up having to tweaks things on the server (you shouldn't but well, shit happens and sometimes it's indeed easier to first get the code back to work on the server), then once it's working manually report your edits to your local repo, clear up the changes on the server and deploy the fixed code again. Here the github repo should be considered as the "master" repository for deployments, ie you work on your local repo, push to github, and on the server pull from github. This make sure you keep the github repo in sync.
wrt/ the "improving functionality" (aka "features") vs "server issues and tweaks" (aka "hotfixes"), git flow is a (mostly) sane workflow IMHO but that's a bit opinion-based here (some dislike it and have sensible arguments too).
Finally if you want to factor out one of your apps, the best is to have it in it's own (github) repo with all the proper python packaging stuff and make it a requirement of your main project. On your local dev environment you install it as an editable package, and for the production setup you install it as normal package pinned to the last stable version. Note that in both cases I assume you're using virtualenvs (and if you dont, well that's the very first issue you should address).
Update:
What are the downsides of of editing directly on the production server and committing from the production server?
Well quite simply a production server is not the place for coding - "production" means that you have users trying to do something with your website and they don't want to have the site breaking on them, their data lost or whatever because you are "tweaking" things. You should only deploy stable, well tested code on production, and the one and only one case where editing anything on the server might be a last resort option is when it's already broken and you want to get it back online asap whatever it takes (case of "first make it work, then make it clean").
Point is, I'm a professional developer working on projects that are business criticals and a broken site is not an option, so I'm very strict on this - but even if it's a hobby project, your users deserve some respect (at least if you expect to see them back).
A proper production chain actually involves at least three environments: your local dev environment, a staging server (which should closely mirror the production server - system, system package versions, configurations etc etc) to test out / showcase / eventually do minor config tweak, and the production server which should only ever see stable tested code.
I have always struggled with git, knowing it well enough to get thigs working, but never being sure I am doing thing well.
I would suggest installing git flow (it is probably available in your package manager if you are on Linux). Its a set of extensions that simplify a standard git worklfow. Since using it, this has pretty much been all the documentation I have needed.
https://danielkummer.github.io/git-flow-cheatsheet/
I have a django app and I would like to have an experience on scaling-up my project.
http://www.djangobook.com/en/beta/chapter21/
In this document scaling issues of django applications are explained very well but before I buy new servers I would like to try the softwares which are mentioned in the document.
Is it possible to run 4-5 virtual machines and install linux servers on each of them in my local computer and distribute database,media and source code of my application on them ?
The reason for that I would like to test the softwares like load-balancers or mysql replication tools before production enviroment.
It is not only possible but very easy. Take a look at the Vagrant1 project. It's a set of small programs built around creating/updating/managing virtual environments for software development.
I'm trying to set up a good development environment for a Django project that I will be working on from two different physical locations. I have two Mac machines, one at home and one at work that I do most of my development on. I currently host a Ubuntu virtual machine on one of the machines to host the Django environemnt, install DropBox on it, and edit source code from my Mac. When I save the code file, the changes get synced over DropBox to the Ubuntu VM and the Django development server automatically restarts because of the change. This method has worked well in the past, but I am starting to use DropBox for a lot of other things now and don't want all of that to be downloaded on every virtual machine I use. Plus, I want to start using Eclipse + PyDev to be able to debug code and have code completion. Currently, I use TextEdit which is great, but doesn't support debugging or completion.
So what are my options? I thought about setting up a Parallels VM on a thumb drive that has my entire environment on it (Eclipse included), but that has its own problems. Any other thoughts?
Here is the environment I set up and it has the components you are after. I have used pydev as well and it works but I prefer Komodo.
Things which I think you are missing:
An SCM - Using Dropbox works but there are some real shortcomings by not using a real version control system. Examples include reverting changes, branching, merging, etc. I agree with Simon
Using a virtualenv will really help when developing on multiple platforms.
I do ALL of this on my Mac:)
HTH
We recently bought a new rack and set of servers for it, we want to be able to redeploy these boxes as build servers, QA regression test servers, lab re-correlation servers, simulation servers, etc.
We have played a bit with VMWare, VirtualPC, VirtualBox etc, creating a virtual build server, but we came across a lot of issues when we tried to copy it for others to use, having to reconfigure every new copy of the VM.
We are using Windows XP x86/x64 and Windows Vista x86/x64, so I had to rename the machine, join the domain etc for every new copy.
Ideally we just want to be able to add a new box, deploy a thin boot strap OS (Linux is fine here) to get the VM up an running, then use it.
One other thing we have limited to no budget, so free is best.
I would like to understand others experiences in doing the same thing.
FYI, I am not in systems IT, this we are group of software engineers trying to set this up.
Any links to good tutorials would be great.
The problem you're running into is the machine SID must be unique for each machine in a domain. Of course by copying an image you now break that unique constraint.
I'd suggest that you read the documentation for Sysprep in the reskit and Vista System Image Manager - your friends for XP/Win2k3 and Vista/Win2k8 respectively.
These tools enable to "reseal" your configured instance of the OS such that the next time it boots - it can prompt for information such as network configuration, machine names, admin user ID's, run scripts etc.
Also be aware that the licencing restrictions for Windows desktop clients are generally per image - not per server.
Using these tools with HyperV we created complete preconfigured instances of Win2k3 & Win2k8 that boot to finish installing Sharepoint - going further we used the diffing disks to overlay Visual Studio so our devs could use the production images for their work. It has radically changed our development process.
At this point our entire public website is run on HyperV with of 5 boxes running 15 images for a mix of soft and hard redundancy - they take several hundred million page views per week.
Another option for dealing with the SID probelm is NewSID. This is a simpler tool than sysprep, in that all it does is rename the machine and reassign the SID; if you don't need all the other features of sysprep this is a much easier tool to use.