There are some queries for which we need resolution before we purchase sitefinity 5.0 license. I would really appreciate if could get answers to these
What are the recommended guidelines to setup the sitefinity project in the source control? If there 4 to 5 developers working on the project, what should be the starting point in setting up the initial codebase? Do every developer has to create the sitefinity website and DB on their dev-boxes?
Is it recommend to setup a common DB for the sitefinity website where all the dev-machine would be connecting to do the development, if not what is the alternative approach?
Is there any online documentation available related to build and release of sitefinity web applications, other than publishing from within the visual studio?
Thanks
Gaurav
We've been developing with Sitefinity since version 2, with multiple developers.
To answer your questions specifically:
Have a single developer (ideally your lead dev) create a clean sitefinity visual studio solution on their local machine. Check it into your source control repository and have each additional developer pull down a copy from there. You're now all in sync.
In terms of database location, two approaches work - either have each person run a local database, and in the web.config setup the connection string location as . (i.e. local). That way no one needs to check out the web.config to run it. Otherwise use a common development/testing server for the database. We've found the easiest way is to each have a local DB, unless multiple devs are working on very specific tasks together at the same time.
I have not seen any online documentation related to building outside of visual studio. If you have TFS or a MS build server, it should work fine as well.
In general, there is nothing 'special' about Sitefinity's architecture that separates it from any other .NET / MSSQL solution. Best practice that falls under these technologies still applies.
My experience with source control has been one of two options. If you are using SQLExpress user instance databases (that is an mdf in the App_Data folder) I've found versioning everything except this database file and the dataconfig.config file in the configurations folder will allow every developer to run their own copy of the website.
from there you can either do some kind of manual merge of the database or just create a new one for deployment.
This option works best if your developers are simply working on features, and don't need to be working on an actual website, modifying content that has to keep in sync.
Alternatively, if they do need to work with live content and it all has to be the same, create the database in a shared server they all have access to, and version everything (since the connection string should be the same for both).
This works best if your developers are doing work to support existing content as opposed to say creating modules that manipulate the database (creating tables, columns, etc), because keep in mind with this method, everyone will be accessing and modifying the same database.
Personally, my preference is option 1, because it allows each developer full control over their environment. the source could then be merged and shadowed to a staging server, so that the main site content is only affected by this one instance.
I hope this is helpful!
Related
I have read multiple posts about this but do not have a clear answer yet.
We are transitioning to EF Core 2.0 company-wide, one project at a time.
The challenge is this:
A new project starts and a database is created using code first, migrations etc.
another programmer needs to create a project targeting the same database.
This programmer can use Scaffold-DbContext and generate current models.
However, a new column is needed and this second programmer adds it.
Now...how do we best update the other projects?
Is there something that checks and syncs or shows what is out of sync between your model and a database? Meaning check the database for changes...not the model.
We don't mind buying a tool if that is the best solution.
The solution we have been using, very successfully is the Database project in Visual Studio.
Using that each developer has the project in their solution, changes are made against it locally.
Then we can do a "Schema Compare" inside of VS.
We have been using this successfully for 4 of us the past three weeks extensively with almost no issues.
This has even worked for keeping versions and changes to our stored procedures current.
It works well with VSTS also.
Here are some of the posts I read that helped me understand it:
https://www.sqlchick.com/entries/2016/1/10/why-you-should-use-a-ssdt-database-project-for-your-data-warehouse
https://weblogs.asp.net/gunnarpeipman/using-visual-studio-database-projects-in-real-life
..and this forum had a lot of relevant questions/answers:
https://social.msdn.microsoft.com/Forums/sqlserver/en-us/home?forum=ssdt
I have been asked by a client to assist in making the web frontends of number of Lotus / IBM Notes databases, used for critical LOB functions, compatible with modern browsers.
As it stands, the web frontends of these databases only work in IE7, and even then they're temperamental at best. The JS uses IE-specific extensions, everything is in tables, and they render poorly on pretty much every browser available today. With IE7 no longer in support, they want to modernise these interfaces.
I have very little experience with Notes, but as an exploratory exercise I've managed to open up the databases in Domino Designer, add a few Stylesheet / Script resources, include them in the $$HTMLHead variable and reworked one Form to use a frontend framework, which looks good.
Obviously working on live applications is out of the question, so my thinking is to take a copy of the NSF files, and make the changes on the copies. My question is: how can I then deploy only the form / subform / resource changes to the 'live' NSF files?
Deployment:
In your new modified database :
You define in the Database properties that is a Database file is a master template (give a name)
In the production database :
first do a backup ! copy (only design) to a new copy of the prod
You define in the Database properties that it inherits from master template (same name)
on the prod make refresh design
more details : https://www.ibm.com/support/knowledgecenter/SSVRGU_9.0.1/com.ibm.designer.domino.main.doc/H_ABOUT_REFRESHING_A_DESIGN.html
Sorry to state the obvious, but since you have a Notes client and a Domino server, you have a quite extensive documentation at your disposal in the form of databases located in the /help/ directory. Make sure they are full-text-indexed.
And since we are on the subject of templates, Domino comes with a host of ready-made, ready-to-use apps that you can customize and canibalize. Look for discussion9.ntf for starters.
You may want to start here, then go there, and finally that will give you the keys to build word-class web apps on Domino.
Last thing, if you are on V9, the Designer help is crap. Grap a copy of the 8.5 version. Seriously.
If you want to build a modern web based front-end to existing Domino data, take a look at the following presentations:
http://www.slideshare.net/TexasSwede/ad102-break-out-of-the-box
and
http://www.slideshare.net/TexasSwede/break-out-of-the-box-part-2
As others already said, you should create a template and then just refresh/replace the design of the production database using that template.
You may want to consider working with an experienced Notes/Domino developer for that project, there are quite a few caveats and workarounds you need to know know about...
I tried to google this but I failed.
Is there a way (I know it is, found this link but with insufficient details) to connect to crystal server's database?
We are runnig many reports daily which sometimes fail, sometimes don't run at all, we accept this as a part of server imperfection. The issue is, that checking each reports instance through CMC is very inconvenient and time consuming. If I could check it directly in some other way it would be much easier to manage.
The server version is 12.0
While the CMS repository is a plain database, querying it directly (using SQL) is discouraged, unsupported and generally a bad idea.
If you want to query the repository, you have several other options:
Use the built-in Query Builder web application (a web application called AdminTools, normally deployed on your application server). This offers a SQL-like interface for querying the repository, though a lot of SQL features are not available (e.g. table joins). Official documentation is also generally lacking for Query Builder, but if you're interested, there's a very good guide available here.
Use the Java or .NET SDK to query the repository. SDK documentation is available on SAP SCN. This is the most powerful option, but also requires you to do everything yourself. And it will take some time to become familiar with all the different classes and how they relate to the BI Platform.
Use a 3rd-party tool. Different solutions exist, with different feature sets, although it seems that most stopped working when BI4 came out, and the ones that exist usually require a server component as well.
Additional information:
How to browse CMS repository (SAP Wiki)
Query Builder in BO – Browse / Query BO Repository
BusinessObjects Query builder - Basics
Using Query Builder to Explore Your BusinessObjects Repository
You could also more-or-less automate the querying of the repository (although it's very basic) by following the instructions outlined in this blog post.
I've been ramping up on Azure Mobile Services over the past week. There are definitely some PROs and CONs in using them over a standard Azure Web Site where I can write APIs that hit SQL DB, etc.
One of the biggest negatives I see is developing the server side code and DB structures ON THE SERVER. I've watched lots of videos from launch and beyond, read lots of blog posts about tips and tricks around WAMS, but nobody seems to talk about the downside of developing the code (server scripts) and database structures on the server, at your live URL.
This is all great for developing the first version of your mobile app and associated mobile services. But once it's all deployed, how do you ever build version 2? Real apps hitting real APIs and data, but now I want to develop/change/play with the server scripts and database schema?
With Azure Web Sites, I can develop locally and only publish code and DB changes to the server on my schedule.
Have any of you seen or heard of the "v2 development story" around Azure Mobile Services?
Only thing I can think of would be to create another set of tables and APIs around them, most likely "virtual tables" that allow me to write APIs against the original set of data. Seems like a huge hassle, since the client code would now have to know about the original set of tables and the new set of tables... that's only for v2...
Thanks for any thoughts / insight.
You should have two services, one dev and one production and use scripts to promote your code from dev to production (pretty similar to how most workflows go, in moving from a test setup to a production one).
http://channel9.msdn.com/Events/Build/2013/3-511
I have been working on a side project for the last few weeks, and built the system with EntityFramework Code first. This was very handy during development, as any changes i needed to make to the code were reflected in the DB nice and easily. But now that i want to launch the site, but continue development, i dont want to have to drop and recreate the DB every time i make a tweak to a model...
Is there a way to get EF to generate change scripts for the model change so i can deploy them myself to the production server? And how do i use the database somewhere else (Windows Service in the background of the site) without having to drop and recreate the table, and use the same model as I have already? Kind of like a "Code first, but now i have a production DB, dont break it..."
Personally i use the builtin data tools in VS2010 to do a database schema synchronization for updating production.
Another cheaper tool if you dont have VS Premium is SQLDelta which ive used in the past and is really good.
Both tools connect to the two database versions and allow you to synchronise the table schemas first. Both also have an export to SQL script functionality.
Comming up for EF is Migrations which allows you to solve just this problem within your solution however its still in beta. Migrations lets you describe upgrade and downgrade events for your database in code.
No RTM version of EF has this feature. Once you go to production you must handle it yourselves. The common way is to turn off database initializer in production and use some tool like VS Premium or RedGate Database compare to compare your production and dev database and create change SQL script.
You can also try to use EF Migrations which is exactly the tool you are asking for. The problem is it is still beta (but it should be part of EF 4.3 once completed) so it doesn't have to work in all cases and functionality / API can change in RTM.