I am aware for Enterprise Architect and version control (using Subversion), projects where each user possesses their own project (.EAP) file, each user must have a local working copy checked out.
In a centralized DBMS repository which allows all users to work on the same .EAP project file rather than having their own, is it a better practice to consolidate to a working copy folder shared amongst all users? Or does each user need to maintain their own working copy similar to a non-DBMS team environment?
I hope you choose another technology then .eap (which is atually MS Access) as underlying centralized repository.
But that set aside, the version control part stays the same. Each user has its own local working copy folder. EA works with exclusive checkouts, regardless of having a central database, or distributed .eap files. So having a shared working folder would not work very well for that aspect.
What we do to make it a bit manageable is to tell users to map their working folder copy to a place in "home" folder (which in this case is mapped to the H:\ drive)
Each user then has H:\SVN\Enterprise Architect\ as their working folder, but under the hood that gets registered as \\servername\username\Documents\SVN\Enterprise Architect\ making each working folder unique to the SVN server.
PS. In my case this was for TFS, but I'm pretty sure the same principles apply for SVN.
Related
In our current dev. workflow there is main database --> DbMain. There is the process that takes the latest version of the project and automatically deploys it there and after that it triggers unit tests. As we would like to always have working version of the project in the source control each developer should be sure that he checks in the working code and all tests would be passed.
For this purpose we decided to create individual databases for each developers that has following naming convention --> DbMain_XX (where XX are the developers initial). So every developer before the check-in is suppose to publish all the changes to that database manually and run the unit tests. It is useful to setup publish config for this purpose with that is the copy of the main publish config with the only difference in the database names.
That would introduce that we will have a lot of different publish profiles in the solution that is quite a mess.
If we will not add these profiles to the source control, then .sqlproj file would still have reference to these files so the project will have reference to the not existing files.
So the actual question. Can I have single publish profile for all developers where the database name will be changed using variables? For example DbName_$(dev_initials)? Or can we have that each developer would have their own publish configs only locally and it wouldn't break the project?
UPDATE:
According to the Peter Schott comments:
I can create local publish profile, but if I don't add it to the source control, then the still be an entry in sqlproj file, but the file itself will be unavailable.
Running tests locally have at least 2 disadvantages. The first one is that everybody is supposed to install SQL Server locally. We are mainly working via virtual machines and the disk space is quite limited there. Another thing is that developers will definitely forget or not will not run tests manually every time. Sometimes they will push changes to the repo without building it or/and running tests. We would like to avoid such situations and "catch" failed build as soon as possible.
Another approach that was mentioned is to have 1 common build database. And in my case we have one (DbMain). All of developers can use it for it's needs but we will definitely catch the situation when the 2 developers will publish at the same time and that can make a lot of confusion by figuring out what's really went wrong.
A common approach to this kind of thing - not only for SSDT publish profiles but for config files in general - is to commit a generic version of the file with a name something like DbMain.publish.xml.template, and provide instructions to the developer to rename the file to DbMain.publish.xml - or whatever - and .gitignore this local copy of the file, allowing the developers to make whatever changes they want, but inherit the common settings from the .template version of the file.
Publish profiles don't need to be added to the .sqlproj to be used at deploy time, this is merely a convenience in Visual Studio to make them easier to find and edit, so you don't need to worry about broken references.
You are right in wanting to avoid multiple developers publishing to a common "build" database, this is a recipe for frustration.
Really, you want the "build" database to be published to as part of your CI process, meaning after the developers have pushed their changes.
i am using wso2 api-manager 02.01.00 on a linux system. The Api-Manager is deployed at Folder A. The Databases (h2) are deployed ad Folder B which is not in Folder A. The datasources in /repository/conf/datasources/master-datasources.xml are pointing correctly to the databases in Folder B. I configured it like that, because i want do preserve the databases if there is a deployment. (Becaus a fiew Developer are using the API-Manager and they don't want to loose their Data.) But it seem, that WSO2AM_DB.h2.db is created new if there is an api-manager-depoyment. I think this, because i had a look to the DB-Size. I started with a Size of 1750KB for WSO2AM_DB.h2.db. I published a view API's in the Manager and the Size increases to 2774KB. Then i did a Deployment and the size returned to 1750KB.
Effect is that API-Store/Publisher says "There are no APIS published yet".
But i could see the APIS at Application Subscriptions and in Carbon Resources at /_system/governance/apimgt/applicationdata/provider/admin.
I tried to force a new Indexing with this, but it doesn't change anything.
Could i configure at any place, that the Database should not be created/manipulated at start?
Meanwhile i'm really desperated of not solving this problem.
Maybe you could help me.
Thank you for your Time.
WSO2 does not recommend to run on H2 database. You need to use a production database such as mysql, oracle, etc. H2 is only for tryouts.
Basically, WSO2 servers store data in databases as well as use the file system. For this kind of a deployment, you need to do the following.
Point to an external database. If you are using this for demo purposes, still you can go with the current mode (H2 database).
Use dep-sync. The content which comes under the WSO2_HOME/repository/deployment/server location needs to be preserved. You can use SVN based dep-sync or rsync. Basic idea is that for a new deployment, you need to have the data of the previous deployment.
Solr Indexing preservation. If you have hundreds/thousands of APIs in the system, it would take time for indexing. To avoid that you can copy the content of WSO2_HOME/solr to the new deployment.
I'd need to have wpf app in a shared folder from where users could make a shortcut and run it having an opportunity to right click on the shortcut and run it also as a different user.
So, I'm wondering if I could copy all files from the bin/release folder if it could work. I did publish the app and installed it on another computer but it seems as there is no possibility to use a right click with the run as a different user. So, I did also copy bin/release files there and made a shortcut from the bin application file and the run as a different user seems as working from that shortcut on that machine. But, it might be not a right approach. The publishing and installing might not be an option further as well as it would need to go through TFS eventually where it would be copying files from a one environment to another.
I did implement it through TFS. The TFS is finally generating mainly the same files as in bin/Release when it's built via VS.
We are developing a moodle site. We are a group of 5 people and each one is working on different module locally. But now we wwant to integrate the work of all in one machine or server. Is there any way to version control it or integrate it as the databse of each one is different because of different data. Please provide the solutuion as early as possible.
It is not completely clear as to whether you are separately working on the content of the site or the code for the new site, so I will attempt to answer both questions.
For content the easiest way to integrate it all together into one site is to use the Moodle backup and restore mechanism ( http://docs.moodle.org/26/en/Course_backup ) - backup each of the courses and then restore them onto the main site. If you have a lot of courses to transfer, then it may make more sense to write some code to automate certain aspects of this, but that can be quite a bit of work, so usually it is easier to just manually do the backup and restore.
For code the answer is Git. All the core Moodle code is version controlled via git. Make sure that each developer is working with their own clone of your main git repository (you can find the core Moodle repository at . Once they have committed each of their changes, then they can be pushed (to a central repository) or pulled to your production site. Read more at http://docs.moodle.org/dev/Git_for_developers
Note that if the code for each module has been written with the proper DB installation / upgrade code ( http://docs.moodle.org/dev/Upgrade_API ) then it should simply be possible to take the code from each of the developed modules, put them together into one codebase and then create a fully-working fresh install. Once you have that, you should be able to use backup and restore to transfer any required courses from the development servers to the live server.
I'm configuring an installer for our product which, up until now, was distributed as a war file, usually on tomcat. Once tomcat has exploded the directory, the user has to open a properties file and set their database connection information. I'd like the installer to do this (we're using install4j) but there doesn't seem to be a built-in way to modify a text file inside a war file. I could just have the installer deploy the app as an exploded directory, which would save me the trouble here, but what do I lose by deploying like that instead of deploying the war?
It might work better to set up the database connection as a JNDI Datasource, rather than hand-editing a properties file inside the webapp/ directory. This is especially important if you want to allow users to re-deploy the application from the .WAR archive without overwriting their local configuration changes.
Of course, the JNDI setup isn't going to be trivially accomplished through the installer, either, since the mechanism used varies from app server to app server. However, any competent Java application server administrator should know how to configure a named datasource. Furthermore, by delegating responsibility to the app server, you allow your users to take advantage of connection pooling, clustering, and any other features provided by the datasource implementation bundled with their application server of choice.
Not much I would think - perhaps a bit of disk space, but if that's not a problem you'd be fine. Have you thought of having the installer generate the properties file and using a ZIP library (.WAR is really a .ZIP - rename it to a .ZIP and see what you get :) ) to replace or add it in?