I set up a development environment and developed a product: it's listed under "develop" in buildout. How can I get the same product running in production? None of the tutorials seem to take it this far, from what I have found. How do I go about making it a fully fledged egg? Or should I run develop.cfg on the production server (I'd think not).
You can continue to deploy the product in 'development' mode; it is just a local egg that'll satisfy all version requirements.
You could publish the egg to an (internal) index server, and use it as a proper buildout dependency, but that is not required. It all depends on your deployment strategy.
For recent projects, we just stuck to the first option; the source of the site is part of the buildout repository, and new deployments are tagged with a version number. The egg remains listed under the develop line in buildout. The extra hassle of creating a production egg just isn't worth it, not when that same egg is never used outside of the site-specific buildout.
I shared your pain for ages. I never did bother to create eggs until I came across Dylan Jay's collective.hostout. It eggifies my development packages and deploys them to as many hosts as I need.
Related
I am developing a meteor application. I noticed that the meteor server sometimes suddently crashes, this makes me think that it might not be optimized for production.
In a production environment, should I consider to add/remove some packages? Which one? And what are the best settings? I just want to make sure to have a reliable server that stay up all the time.
Have you taken a look at meteor up yet? It will set up a production quality server for you. I've used it for several production applications and it works great.
As far as adding/removing packages goes, I've never ran into any problems with installed packages running on production. A couple of my apps have about a dozen or so packages installed. But if you suspect that a package might be causing the problem, I would go to atmosphere and search for your packages and make sure that they haven't been flagged. You'll see a bright red flag next to the package name if it's been flagged by the community as "not working".
Maybe also check for issues on GitHub.
If you do decide to use meteor up, after your app has been uploaded to the server, you can check the log s for any problems.
mup logs -f
We use artifactory as a repo manager. We store packages for releases in repo libs-release-local and snapshot packages in libs-snapshot-local.
For example: If we send the war (web app) into test, it should be from libs-snapshot-local and if it is into stage & prod it will be from libs-release-local.
I will say a scenario, where I needed help below:
Once the war is certified good on test server we would send the same code to stage.
We saw a bug after deployed into stage, so we changed the code and again build it, it obviously cannot go to same versioned release(as in artifactory, we cannot override releases).
So,
What will happen if we recognized 10 bug fixes one at a time, after each deployment in stage ?
What if we have realized there are bug fixes after going to prod.
Artifactory will have bulk of folders with so many version names & folders. Is that good practice? Or else anything senses wrong in our procedure?
Thanks!
Suggest to read Binary repository management Refcard first.
You need define your strategy for your folders and wars (web application), it is already good to use different repo for different purpose (snapshot/release)
The process for maintenance is simple
fix the bug and increase the version, send to the libs-snapshot-local for testing
after testing, a.k.a QA passed, the packages are promoted to release/stage repo libs-release-local again for public use again.
In this case, bug fix is the same as normal development procedure.
or you can refine the questions to make your questions more clear.
Net solution for a website, consisting of 5 projects, and there are a few(less than 10) developers working on the solution. We deploy almost on a daily basis.
The question is, how to setup the SVN repo to support this scenario (the daily deploy), also mentioning that not every commited file should go to production, there is a QA check before deploying.
Try out TeamCity
(CI tool) as its free for smaller amounts of CI. this may be better for you than CruiseControl.Net as CCNET is very configuration heavy as its all done via XML. TeamCity uses wizards to create the scripts to manage releases
if you need any other help on CI then let me know as its something I am evangelistic about.
What you want to do is commonly referred to as Continuous integration (CI).
While you can do that using Subversion, it is probably not the right tool for the job.
There is special CI software, which will allow you to easily automate the necessary tasks (checkout from version control, compiling / building, running automatic tests, deployment etc). An example would be CruiseControl.NET.
As to "not every commited file should go to production", the common solution is to have a special "release" branch, which gets deployed. Only tested code is merged there (or have the trunk always be stable, otherwise same model). Of course, you can also (better: additionally) have tests before your automatic deployment, and only deploy if all tests pass.
Working with a release branch
In practice, this means that people check in their code as they produce it. Sometimes this code will work, sometimes not. When the release time draws nearer, a "release branch" is created in Subversion. This release branch is then effectively a frozen snapshot of the source as it was at the time of branching. Now this branch can be used to compile & deploy the application, which can then be tested.
No new code is checked into the branch (but checkins can continue elsewhere). Only if a bug is detected in the branch, will there be a checkin into the branch to fix it. This continues until the branch passes all tests. Then the branch can be released as a new version of the software; afterwards the branch will only be used if the released version needs to be patched.
Of course, any bugfixes checked into the branch need to also be put into the trunk (either by merging branch -> trunk, for which Subversion provides special support, or by reimplementing the fix in the trunk, as appropriate).
I have a Windows 2003 Server with IIS, I installed VisualSVN Server on it.
I have two developers, who are going to use TortoiseSVN.
Since this is my first time ever setting up a SVN server I am kind of confused on how this will all work. The way I see it, each developer would have a copy of the repository on his or her local pc, would each person be required to have IIS installed on their PC as well to test their copies before checking out?
Should I create a testing folder on the server and then a production ready? It seems as if that would cause more issues with copies?
What would you do?
EDIT
I dont know what I was thinking, I forgot that VS has a built in IIS when you debug so the issue about setting up IIS on either client or server is now a non-issue. But I am confused, I imported the site into the repo, it said it was on revision 2 but I dont see any of the files in the repo folder. Do I create a virtual folder in IIS pointing to the repo that I created?
No, each developer uses your repository, and checks out their own copies to do their work. They do not need IIS or svn, etc, installed on their systems.
I recommend reading up on the Subversion FAQ.
Your devs don't have a local repository, they have a Working Copy on their PC. Typically, this is the most recent version of the app with whatever changes have been made by the developers but not committed yet.
As this is a web app, then your developers will need some kind of web server locally to test it - this could be IIS, or Visual Studio's built in web server (although that does behave differently to IIS in subtle ways).
You said in a comment: "My problem is I dont want the devs to commit to the live site in case there was a bug.".
The devs commit to the SVN repository on the server: at some point you will want to export (aka 'publish') a copy from the latest version in your repository to your live site. In order to make sure this works, you can check out a specific version from the server, test it, and if it passes the tests upload it: devs will always check in code with bugs (even though it builds) as it's better to check code in frequently than build up lots of changes locally then commit them, as there are bound to be conflicts with work other developers have done.
Branching and Tagging are useful concepts here: when you have a version which is almost right, you 'branch' it away from the main 'trunk' of the source code tree, fix any issues in the branch (back-porting to the main trunk as required), then when you have a working version you 'tag' it (as version x.y.z) and upload it. This way you can always refer to the particular version of the code you have uploaded, which makes it a lot easier to identify bugs which turn up in production. As others have suggested, read the SVN documentation for more info.
It depends on how you work. There are other discussions about folder structure and such which play directly into how you use version control.
Uh, no, no local repositories. Setting up SVN is easy, well almost. You'll want to look for the svn windows installer and set it up on the server. You'll want to install Apache and then you'll have a little hurdle setting up the http.conf file to expose svn over http. There's a little complexity with setting up security so go with Windows Authentication, you'll need WebDav, google it.
Once that's done, any svn client can hit it and checkout a copy and work with SVN normally. If you get really stuck, comment here and I'll go get a copy of our install and config for you.
The good news is that it's rock solid, once you get it setup it'll run forever.
"Pragmatic Version Control Using Subversion" and the SVN red-bean are the two sources you need to see.
Set up SVN on a single server and have all your developers point to it.
I've installed tortoise on the server and do Updates / Checkouts of the release website. Some people don't like checking in compiled code, but I like having the production compiled site in SVN.
If you use tortoise on the server, Do the initial checkout to the inetpub/website directory and then on rollouts you just need to update the directory using tortoise->update
Of course checkin to rollout is considered bad practice without first rolling out and testing on staging servers, but depends on your team size.
I have used the following resources for learning SVN:
http://www.polymorphicpodcast.com/shows/subversion/
http://www.dimecasts.net/Casts/ByTag/SVN
Found both quite good, and learning by watching can be easier especially for getting started.
No - your central server will maintain the repository. Your developers will get copies of the repository, make changes, and then commit them to your repository.
You actually have quite a few things to figure out if you want to do a successful deployment of subversion.
One really good article about setting up subversion on Windows - https://blog.codinghorror.com/setting-up-subversion-on-windows/
No, SVN server must be installed on a single computer. Each developer point at this computer and get locally (and eventually) a full copy or a partial copy of the repository.
You may also buy a book from O'Reilly about Subversion. Don't remember the title, sorry, but it helps me a lot.
All the best ! Sylvain.
After a lot of trial and error (mostly due to lack of documentation and examples) I have managed to create MSI installers that install custom DLLs to WinSxS as side-by-side assembly. There is only one problem: Uninstalling leaves all files (DLLs, manifests and catalogs) in the WinSxS directory. How can or should I best clean that up? I know for sure that nothing else references it.
I have read somewhere that WinSxS has a self-scavenging process that cleans up over time but I could not find more information about that. Can you manually invoke this to clean up stuff?
The only other way I see is manually deleting those bits. First you have to change the owner of all files (assembly, catalog, manifest and their respective directory) from SYSTEM to an administrator account, adjust the permissions and delete them. There are also pieces left in the registry (I think HKLM\COMPONENTS\DerivedData\Components may be one place), but since WinSxS should be treated as opaque it is hard to find any information.
Scavenging isn't exposed anywhere that I know of. I'm not even sure when it is kicked off automatically. Maybe on uninstall of a service pack? Maybe some tool admins can run? I really forget.
Anyway, my suggestion is don't fight it. There are so many twisty turns down there that it just isn't worth trying to get the disk space back. Once uninstalled the bits still in the SxS cache will not be activated so they are just wasting space.
It's a dumb design but blame Microsoft and don't try to overcompensate.
Here is an article, it's kinda complete guide to WinSxS.
So, shortly, you can only uninstall some components (all their versions are in this folder), and you can run Service Pack bridge burning utility (in Vista it is named VSP1CLN.EXE and shipped with SP1). Note, that after execution, you shouldn't be able to uninstall SP or any components to state, prior to SP release date.
No-one is convinced you can - short of a complete reinstall, your bloaty WinSxS directory is there to stay.
There's been a long "discussion" of the problem on technet.
There is no documentation of the format, or any instructions how to remove files that are no longer needed - MS seems to think that disc space is cheap. There is a self-scavenging feature, but no-one's convinced it works, or if it does, it is very conservative (as you'd hope as you don't want it to break your OS)
You can tell is the scavenger is working by checking the "C:\Windows\winsxs\Temp\PendingDeletes." folder, as this is where files are moved by windows update or an installer moves them to - the scavenger just deletes the files in here.
You'll notice that after you uninstall your assembly, while the files are still there, they can no longer be bound to - so they are just "staged", or cached, but not really installed.
Rob & gbjbaanb are correct - you cannot manually invoke a scavenge yourself. Don't try to delete the files yourself - there are multiple places in the registry where they are registered, DerivedData\Components being only one of the many references.
I think the rule for Vista is scavenging is kicked off by the TrustedInstaller service after 10 minutes of machine inactivity, after the last servicing operation (service pack, hotfix, etc). But it's very fickle, so it doesn't run as often as it should. So just be patient, and the files will disappear on their own.
Well i was having some issues as i have an 80GB SSD for my windows and the WinSxs folder was about 12gb's
I was searching the net and i found this command:
DISM.exe /online /Cleanup-Image /spsuperseded
And now my WinSxs is 7gb which was wonderful news.
There are a few updates regarding the cleanup method that apply to newer OS. Check http://www.karafilis.net/winsxs-cleanup