I am using the embedded version of RavenDb and have put the physical database in the App_Data folder, based on this article http://msdn.microsoft.com/en-us/magazine/hh547101.aspx. My first question is, what portions of the db need to be committed to the SCM repo?
The second question is, My workflow is such that I'll also use web publishing directly from my laptop, are there any concerns using this methodology?
Thank you,
Stephen
There's no need to put your database under source-control since your documents have no particular schema. They will be created on the fly when serialized into json. So as long as you check in your C# classes, you're all fine.
First, are you aware that RavenDB uses the AGPL license? This license requires that you publish your project as open source if you are not paying for a commercial license.
They do offer free licensing in some cases but you must contact them and get a license. Check their licensing page for more details.
Second, You proably shouldn't check your database into your SCM. Databases change frequently, and SCM is designed for files that not constantly changing. You might want to check in your database schema as it changes... but not the database itself.
Regarding your second question, i'm not sure what concerns you're talking about. Can you be more clear about what your concerns are?
Related
It's unclear how the repositories are connected and tied together. Each git repo has a different package of cs files, with their own unique features and design schemas. Rather than a hierarchical design structure, where in my understanding or example:
Abp-base (free git repo), would have core essentials
AbpZero-paid (membership subscription to premium git repo), would add additional features into their design that would encourage others to pay for.
AbpZeroTemplate-demo (download from website, not git), would be a sample utilizing the paid content to push and drive sales to unlock the tool to it's full potential.
I downloaded and even paid for the different tiers, but all of the contents are all over the place. When I tried to combine them so that I could take advantage of a complete product, nothing lined up properly, and I get breakage everywhere.
How am I supposed to change the crucial schema design flaws when half of the .proj links to .dll that expect the class to be structured a certain way?
Example:
User is structured: "Name", "Surname". But i want it to be "Firstname", "Lastname." Some may ask, what's the difference? Just like how "Maiden name" is different from "Last name" or "Family name." Those little nuances are'nt procedural thinking. If you went to a stranger and asked "what's your name?" and they said "Chuck Jones," you would then ask to clarify, "What's your first name?"
Each git repository is running off of a different versioning number, that doesn't match with their counterpart. AbpZero is on a stable release version 5.x, and you go to GitHub for Abp and it's saying version 3.x is stable and green. And one of them is using User<TTenant,TUser> as a class, and the other is using User<TUser>. So not only am I getting mixed signals on how they're supposed to work (because git repos point to each other, and rely on .dll for continuity) but they're also not even sharing the same coding structure.
Can anybody help me merge the old and new together, or tell me the direction on how the design is being built?
Disclaimer: I'm a contributor to ASP.NET Boilerplate
ASP.NET Core is a web framework developed by Microsoft, as you know. There are plenty different applications based on it.
ABP is an application framework on top of ASP.NET Core (and MVC 5.x but it's a different story - I skip). It tries to help real life applications on top of ASP.NET Core. It has many features like advanced authorization, background jobs, javascript proxies, DDD infrastructure and so on.. This is completely free and developed on Github: https://github.com/aspnetboilerplate/aspnetboilerplate Thousands of developers are actively using it to build their applications.
ABP framework does not provide a User Interface itself, but provides the infrastructure. So, you should create an empty ASP.NET Core application, add nuget packages, configure the framework and modules, create a UI layout and some basic pages to start your development. This is also a time consuming work. That's why we have created "STARTUP TEMPLATES". There are two startup template:
(A) A free & open source startup template can be downloaded here: https://aspnetboilerplate.com/Templates (It just gets the code from https://github.com/aspnetboilerplate/module-zero-core-template and renames solution for you). This is a simple startup template (but more powerful then ASP.NET Core's standard template when you make File > New Project).
(B) A PAID startup template, which becomes the product on https://aspnetzero.com/. This template has much much more features on top of the framework. You can see all on its web site. Since it's a paid product, the Github repository is private and only available to paid customers.
You either start with template (A) or template (B). You CAN NOT combine them. I believe it's very obvious. For instance. Microsoft provides different startup templates for ASP.NET Core: One of them is Angular, one of them is Razor Pages, one of them is empty... and so on.. So, you select one of them based on your needs.
Both of (A) and (B) templates work on the ABP framework and adds via nuget packages (it's already combined/integrated).
So, after this explanation, I believe no one would even think how to combine them.
How am i supposed to change the crucial schema design flaws when half of the .proj links to .dll that expect the class to be structured a certain way?
When you use a framework or a pre-build solution, you have significant advantages. However, there is nothing in the World that has only advantages. Every solution/framework/library will come with its own limitations, you like or not.
With that in mind.. Despite of other vendors, we provide the FULL SOURCE CODE! User class or another schema class is not inside a CLOSED/SECRET DLL. They are on nuget packages and are open source as I described before. They are framework code. If you want to change the framework code it's always possible. Just download the ABP framework on Github repository, include into your solution, remove nuget packages and add project references. Then you can freely change the User class. Source code is open & here:
https://github.com/aspnetboilerplate/aspnetboilerplate/blob/dev/src/Abp.ZeroCore/Authorization/Users/AbpUser.cs
https://github.com/aspnetboilerplate/aspnetboilerplate/blob/dev/src/Abp.Zero.Common/Authorization/Users/AbpUserBase.cs
Each git repository is running off of a different versioning number
Why we follow the same version numbers for different products those are released and developed separately? Does Microsoft have same version number for all products?
I wish i had enough money as the next guy to afford throwing around $1600 a year just to resolve issues with poorly documented code, but sadly i do not
There are thousands of customers paid it and they are happy about our product and they are renewing their licenses to be able to access to latest source code after 1 year. If anybody wants a refund, we always provide a money back without any question. Refund request ratio is smaller than 0.5% because developers love our framework and product.
My membership expired while i was resolving conflict issues with the code, and i immediately lost the ability to use git repo connected to that service
You can contact info#aspnetzero.com and request the latest version of the code (when the time your license expired). We always help to our customers about that. It would be better if you had contact with us.
We have 5 environments - Development, UAT, Staging, Live and DR.
Having more than 100 content editors, makes the Live Sitecore database content grow faster.
So almost every fortnight the content tree is out of sync with Development and UAT environment. When we try to develop new things, it is out dated content and sometimes new functionality breaks the live environment.
Please can anyone suggest an ideal way of keeping all the Sitecore databases in sync apart from creating packages and updating regularly so that we can follow a proper CI?
RAZL is not a solution that you should rely on for Continuous Integration, it's merely a database comparison tool.
Setting up proper CI for Sitecore is exactly what I'm doing for my current project and this is what we came up with:
TDS:
If you are willing to spend money, then take a look at TDS (Team Development for Sitecore).
It integrates with Visual Studio and provides you with tools for serialization of Sitecore items which you can then store in your source control.
A build server would then be able to pick up any changes in those serialized files and deploy them to your Test, Staging and even Production environment.
Alternative:
A free alternative to this is to use a combination of three open source modules:
Unicorn (for automatic serialization of your changes to Sitecore
items)
Courier (for package generation based on serialized items)
Sitecore Ship (for automated deployment of Sitecore packages)
I'm working with the free alternative myself at the moment and it works great.
Have you come across RAZL, it is a Sitecore Database Comparison Tool.
This is what they say about Razl:
Razl allows developers to have a complete side by side comparison between two Sitecore databases; highlighting features that are missing or not up to date. Razl allows you to find that one missing template, move it to the correct database.
It is quite incorrect to call Razl 'merely a database comparison tool' - from the first release, you could copy subtrees from one Sitecore database to another.
The initial drawback was that it could not be automated, but with Razl 3.0 (I think it started with Razl 2.4), Razl scripting was added, so you can easily automate Sitecore database syncing between environments.
To see how others use it, see Sean Holmesby's comments:
https://community.sitecore.net/developers/f/8/t/1767
and Nikola Gotsev's comments:
https://sitecorecorner.com/2014/10/27/the-amazing-world-of-razl-part-1/
It is very inexpensive, and with v3.0, it is much more powerful than the initial release, which required manual manipulation via the GUI interface.
We have a website application that stores data and pictures for a specific customer. We are about to release the same application for use by another customer. The second application will eventually be customized for the second customer. Eventually we hope to have several customers using their own versions of the application.
We are using ASP.NET in Visual Studio 2012. Should we:
clone the existing application and maintain separate code bases?
add a project to the existing solution for the new customer?
We have searched for an answer to but this seems to be a rare situation.
Thanks.
I dont think its rare at all. SAP and Maximo use this a a businiess model. Same core but each package customized to the clients specifications. I have done this (on a much much smaller scale) with some of the programs that we have.
We always start a new project rather than just copy the old. No telling what is in the old one that references the old client. Sort of embarasing when an About window that you forgot about is for someone elses company.
All the code, forms, reports that are customizeable should be in the project for that customer. All of the code, forms, reports that are standard should be in a library.
It really depends on the scope of the application. I've had to do this internally with the company I'm working for; I wrote one solution for one company, then the sister company found out and wanted the same and had to implement it there.
I had a fairly small project to work on, so it was easy to make it universal (while also keeping things rooting from the same code base). All i did was:
break out the unique setting [page title?] using appSettings or similar.
add a new configuration to your solution. Then take advantage of the *.config migrations to:
set connectionStrings
specify appSettings values
When it comes to unique business logic, I had the luxury of using the *.config migrations (most of the data I gathered came from WCF endpoints of services local to the company)--so I lucked out. However, you could make generic interfaces within the app then break out implementation for each company in to separate libraries.
We're having a spirited discussion about this at my workplace. We're talking about user uploaded images for a bunch of products, not images needed to display the basic site. I say "no way" but I'm curious what others think.
Update: Just to clarify. These are customer supplied images for products that they are entering/modifying.
I agree with 'no way'.
Anything that may change on the site through day-to-day use, or is editable by whoever administers the website I consider to be 'content'. This includes uploaded files and database content, both of which are backed up separately. Nothing on the website that is in version control changes once it's been deployed. Easier that way.
Other ways of asking if something should be in version control:
Do the images change?
Are the changes related to anything else?
Can mistakes be made?
Is traceability wanted/needed?
If the rest of the site is version controlled, version control the images.
If the images are generated, version control the generator.
Presumably, what you are talking about is content that would be classified as user data, as opposed to project files. That stuff, while important, does not need versioning - that needs a plain old backup mechanism.
I recently added a new project into a fresh SVN repository, and every time I look at the 'uploads' folder I realise how stupid I was to include that in the initial commit.
It seems like what you're talking about is content that is in (or perhaps will be) in a database. If a customer is supplying you a list of products as well as the pictures of those products, then that should all come from a database. In this case, I wouldn't because your database should be backed up, but not in the VCS.
If it is not, and your web site is static, then I would only because it is "part of the site."
If you feel you must revision it, put these resources out of the path of the main repository somehow, and then give it a dedicated repository just for that content.
You don't want everyone who has to check out code getting a copy of every image when they checkout or update, its slow, and pointless, and having them in your primary tree will just have more headaches than you can Imagine.
/common_ancestor
/project_code/ # repository a
/resources_dir/ # repository b
If you have to use symlinks or web-server magic to make this happen, then do that, but whatever you do, DON'T put content like that in your main repository.
As far as backups vs revisioning go, revisioning it like this does give you a slight ease if you're using SVN as your distribution method as well, that way if a developer needs a copy of the images for testing purposes, its relatively easy to get a relatively up-to-date set of them.
If you aren't going to expose the versioning to the customers, then what would be the point?
The customers are already free to use version control on their own end, before they submit the files. You may want to encourage them to do so.
I'm working in a multi-developer environment in Oracle with a large package. We have a DEV => TST => PRD promotion pattern. Currently, all package edits are made directly in TOAD and then compiled into the DEV package.
We run into two problems:
Concurrent changes need to be promoted on different schedules. For instance, developer A makes a change that needs to be promoted tomorrow while developer B is concurrently working on a change that won't be promoted for another two weeks. When it comes promotion time, we find ourselves manually commenting out stuff that isn't being promoted yet and then uncommenting it afterwards...yuck!!!
If two developers are making changes at the same exact time and one of them compiles, it wipes out the other developer's changes. There isn't a nice merge; instead the latest compile wins.
What strategies would you recommend to get around this? We are using TFS for our source-control but haven't yet utilized this with our Oracle packages.
P.S. I've seen this posting, but it doesn't fully answer my question.
The key is to adopt a practice of only deploying code from the source control system. I'm not familiar with TSF, but it must implement the concepts of branches, tags, etc. The question of what to deploy then falls out of the build and release tagging in the source control system.
Additional tips (for Oracle):
it works best if you split the package spec and body into different files that use a consistent file pattern for each (e.g. ".pks" for package spec, and ".pkb" for package body). If you use an automated build process that can process file patterns then you can build all of the specs and then the bodies. This also minimizes object invalidations if you are only deploying a package body.
put the time in to configure an automated build process that is driven from a release or build state of your source control system. If you have even a moderate number of db code objects it will pay to be able to build the code into a reference system and compare it to your qa or production system.
See my answer about Tools to work with stored procedures in Oracle, in a team (which I have just retagged).
Bottom line : don't modify procedures directly with TOAD. Store the source as files, that you will store in source control, modify then execute.
Plus, I would highly recommend that each developer works on its own copy of the database (use Oracle Express, which is free). You can do that if you store all the scripts to create the database in source control. More insight can be found here.
To avoid 2 developers working on the same package at the same time:
1) Use your version control system as the source of the package code. To work on a package, the developer must first check out the package from version control; nobody else can check the package out until this developer checks it back in.
2) Don't work directly on the package code in Toad or any other IDE. You have no clue whether the code you are working on there is correct or has been modified by one or more other developers. Work on the code in the script you have checked out from version control, and run that into the database to compile the package. My preference is to use a nice text editor (TextPad) and SQL Plus, but you can do this in Toad too.
3) When you have finished, check the script back into version control. Do not copy and paste code out of the database into your script (see point 2 again).
The downside (if it is one) of this controlled approach is that only one developer at a time can work on a package. This shouldn't be a major problem as long as:
You keep packages down to a reasonable size (in terms of WHAT they do, not how many lines of code or number of procedures in them). Don't have one big package that holds all the code.
Developers are encouraged to check out code only when ready to work on it, and to check it back in as soon as they have finished making and testing their changes.
We use Oracle Developer Tools for Visual Studio.NET...plugs right into TFS
we do it with a Dev database for every stream, and labels for the different streams.
Our Oracle licensing gives us unlimited dev/test instances, but we are an ISV, you may have a different licensing option
You can use the Oracle developer tools for VS or you can use sql developer. SQL developer integrates with Subversion and CVS and you can download it for free. See here: http://www.oracle.com/technology/products/database/sql_developer/files/what_is_sqldev.html
We use Toad for Oracle with the TFS MSSCCI provider against TFS 2008. We use a Custom Tool that pulls database checkins from source control and packages them for release.
To my knowledge Oracle Developer Tools for Visual Studio.Net doesn't have any real source control integration with TFS or otherwise.
You might consider Toad Extensions for Visual Studio though it's not cheap, maybe $4k I think.
Another option is the Oracle Change Management Pack but believe it requires the Enterprise edition of Oracle which is much more pricey.
You may be interested in Gitora www.gitora.com. It helps managing Oracle database objects with Git.
This article about collaborative development with the Oracle database can also be helpful: http://blog.gitora.com/plsql-how-to-develop-two-features-simultaneously-but-deploy-only-one/
Full disclosure: I am the developer and author of the article.