Why does redmine not use the development and test environments?
In the official installation guide they only show one environment when setting up the databases, advise to run bundler skipping dev and test, and run the rails server in production mode.
I think this instruction describes the installation process only for server (which runs in Production mode). I think it is done this way not to confuse new users (who do not have a lot of knowledge in Rails)
You can easily use this instruction to setup Redmine locally (I did it successfully several times ;). In order to install Redmine locally you should change only few points in the instruction.
Related
We're using the hosted build agent on VSTS to build and release our ASP.NET Core code to Azure App service.
My question is: can we run WebPack to handle front-end tasks on this hosted build on VSTS or do we have to do it manually before checking the code into our repository?
Update:
I'm utilizing the new ASP.NET Core Build (Preview) template that's available on VSTS -- see below:
Here are the steps -- out of the box:
For VSTS we're working on an extension, currently it's in beta phase, you can ask for a share.
Check the VSTS marketplace.
Check this github repo.
Webpack is definitively not a first class citizen for VS2015 and VSTS. Streamlining webpack for CI/CD has been a real headache in my case, especially as webpack was introduced hastily to solve dreadful performance issues with a large monolithic SPA (ASP.NET 4.6, Kendo, 15,000 files, 2000 folders). To cut short, after trying many scenarios to make sure that freshly rebuilt bundles would end up in IIS and Azure webapp, I did a 2-pass build. The sequence of VSTS tasks is as follows: npm install global, npm install local, npm webpack install local, npm webpack install global, build pass 1, webpack, build pass 2, etc... This works with hosted and private agents, providing you supply the proper path for webpack as webpack is installed in a different location in host and in private (did not find a way to chose the webpack install location for consistency). I scorch everything before starting the build. Also need to do these in VS2015 solution : (1) unload "built" folder, and (2) Add Content Include="Built\StarStar" in project file. The "built" folder contains the bundles and should appear greyed, otherwise more bad surprises and instabilities to deal with...
Build-Pass #2 task in VSTS BUILD allows to collect the fresh bundles generated by Build-Pass #1 and includes them automatically in the package to be published.
Without a second build-pass, collecting the bundles and merging them in the zip package is a nightmare, especially when you have 15,000 files to unzip then rezip (300 ms per file!!). Did not find file-merging capability that I could readily use in VSTS.
I have my hears to the ground listening for someone coming up with a more efficient CI/CD scheme for webpack. In the meanwhile, my 2-pass-build workaround is working flawlessly, but slow indeed.
I anticipate that the advances with ASP.NET core, Angular 2 and webpack will look into solving this elegantly.
I chose Vagrant so that other developers in my team can quickly start contributing to the project. Is there anyway we can also make it easy for the developed code to be deployed on EC2 or Azure servers? If there are any articles on the optimal setup, please point me to them. Thanks!
The first video of Getting started with Django shows how to use Vagrant for locally Django developing and how to use it for deploying it to Heroku, you may want to use the first part of the tutorial (the one related with the local development). For the second it depends how you are going to deploy it, but as long as your code will be in a Git repository, you could clone it to EC2/azure from git.
We are starting a web project with Django (and are pretty new to this), and I was wondering what would been the best way to setup a productive development environment.
Here is some info:
We are 2 developers working on the project
We have a development/production server hosted on Webfactional (using an apache server)
The DB (MySQL) is hosted on this server
We are both using Eclipse with Pydev
The project is hosted on a Github repository
So far, we didn't setup any local development server, we are syncing modifications to the server through Github. But it is not really convenient...
We were thinking of setting up apache servers locally, that uses the remote database, and only sync once in a while.
Do you think it would be better?
Do you have other ideas/additional tips?
Thanks!
Don't try and share servers and databases while you're developing. You'll only get confused.
Each developer should have a local copy of MySQL on their own machine, and run the development server as mipadi recommends. Manage db schema changes via South, and keep data in fixtures or use South's data migrations. Each developer should commit to their local version of the git repository, but only push changes to Github when the particular task is complete and working (or, better, use a remote branch so that changes are synched, but only merge back to master when complete).
A good idea is to have a continuous integration server like Hudson/Jenkins that, after each commit to master, runs the tests and - if they pass - builds an up-to-date version of the site, which you can use for functional/user testing.
Edit to add There's no relationship between the development server and any particular database backend. As I recommend above, it is quite simple to install MySQL or PostgreSQL on your local machine, and use the development server against that. I have been working this way for several years, after initially encountering some of the issues you were worried about when switching between sqlite3 and the production MySQL db.
Django has its own development server that you can use for local testing.
I'm new to django and my very first project is my blog. I wonder how django developers who use pydev normally synchronize with remote hosting server, updating their sites?
I also would like to know, how do you combine usage of git with a django project? Should I just make a repository for the entire project?
At my company we've got an entire git repository for each project, including the Django sources that are put in the PYTHONPATH for each project, making Django versions project dependant. The folder structure is something like:
/.git
/projectname/app1
/projectname/app2
/projectname/manage.py
/django-lib/django/...
As django-lib is not a Python module, we include both / and /django-lib in the PYTHONPATH. If your project is becoming large, you might want to consider using git submodules on your apps.
We've also setup several servers to support the developers. There's a testing server running a central testing database and a setup including Apache with WSGI to make testing on a real server possible, which sometimes is a bit different then the local manage.py the developers use before committing their changes.
The testing server is updated with the master branch of our git repository. We've made several scripts to allow all developers to do this without letting them login to the server via SSH, but that is just during pre-release. After release, that server will become our staging server, and we'll remove all scripts from it to make it just like our production server.
Every developer has setup their local project to make sure that it communicates with the central testing database, containing several test data. I myself push my changes from the commandline, but you could also use EGit for this.
When we've got a release, we put it in a separate branch, called 'release' (obviously) and the production server will pull only from that branch. This is done via SSH, but I don't really know how your server setup looks like, so I guess that that last step is entirely up to you.
I hope that this has helped you a bit. I won't say that this is the best workflow possible, but it works for us and you should figure out what works for you.
Most experienced Django developers use pip(or distribute) and virtualenv deal with all the python packages you might need for your Django projects (including Django itself).
Personally, all I keep in my projects git repository is a bunch of segregated requirements lists generated by pip :
. ~/Dev/environs/$PROJECT_NAME/bin/activate
pip freeze > ./docs/requirements/main.list
I'm fairly sure most django developers would be familiar with Fabric, which I use for :
streamlining local interaction with git and,
pushing to our central repository,
pulling from our production or test server
touching the wsgi on the relevant server
and pretty much any other kind of task you might find yourself using ssh terminal session for.
For those cases where I need to make changes to someone elses django application in order to make it work or suit our purposes, I :
fork it on github,
clone from my forked repo
make the changes
push it up to my own repo
and provide merge requests to the original repo owner
This way, i have a repo where i can use pip requirement lists to keep pulling from until the original application owner gets their own repo updated.
I have deployed several Django-driven sites, mostly "concept" stuff; nothing serious. Now I'm ready to deploy a real-deal site (for my brother's medical practice), and would like to ensure that I'm doing it correctly.
My central concern, is the testing environment. I had been doing it by maintaining two separate folders with different Mercurial copies of a site, then updating the development branch, merging with the release branch, and then uploading to the server (Webfaction).
How do you manage testing environment for your Django projects?
All development is done on my local machine. I use virtualenv (and virtualenvwrapper) for the multiple projects. With virtualenv, you can have several versions of the same software without having to 'break' other code that may depend on a certain version. I use pip for downloading the proper libraries/applications into these separate environments. For each project (and therefore environment), I have a mercurial repository. If the new development passes all unit tests and works as expected, I send it up to the VCS. Once in the VCS, the code gets reviewed by colleagues.