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.
Related
I have an understanding that it might be the DBA's job to push the changes, much like a refresh, but without the DML (Data Manipulation).
Any comments/suggestions will be great!
There is no simple answer for this, but essentially the task of deploying code is similar for any computer language, with the main differences for the database component being
We can't drop and rebuild tables because we need to keep their contents.
Our code compiles in the database, so there are no binaries to deploy.
The first rule for PL/SQL development is that you should always, always work from source-controlled files, for example the code for mypackage would be in a source file named mypackage.pck (or whatever file extension works best with your chosen IDE, as long as it's not .sql). Don't edit database source code directly except for trivial testing when you don't care about keeping the changes.
Some sites only ever do incremental deployments, while others use a full teardown and rebuild from a release branch for major releases, which takes a bit more thought but is ultimately cleaner. Then deployment consists of running the scripts, recompiling the schema and perhaps running some tests and checks to ensure it has worked. You'll need a branching strategy, perhaps some kind of 'run everything in this folder' script, and ideally some tools such as Team City or Jenkins to automate as much as possible, though I don't think there is as much out there ready-made for PL/SQL as there is for more mainstream languages such as Java.
The deployment process is usually performed by an application support team as it does not require any DBA privileges unless you are creating schemas or roles etc, although some sites may organise support roles differently.
Yes. Partially it will involve DBA. But, as the developer, you probably need to provide the entire DDL script by exporting (probably in a file) to the DBA to deploy.
Check 'Importing and exporting SQL scripts' part of this link for exporting db scripts: https://docs.oracle.com/cd/B25329_01/doc/appdev.102/b25309/sql_rep.htm#BABBHEHA
I have a few (3) core projects I want to share across many solutions (12+).
So, say I have 12 websites and they use some shared back end core code (in this case I'm not talking about shared js, css or views - I'm talking about business objects, entity stuff, etc.).
I need to be able to identify which site has which version of the shared code in dev, test, prod, etc. so a developer can get the website code and get the right version of the shared code to develop or patch the website.
And then the MS build server needs to know which version of the shared code to get for the deployment.
To solve this, I'm seeing people branch that core code - which seems absurd to do 12+ times. (I do expect to branch the core code sometimes for things like hot fixes and long running projects.)
I'm also seeing people copy DLLs of the core code and check those in.
I would think I would list the dependencies for my solutions based on TFS label names somewhere so developers can easily get the apps running with the right code and given a tfs label the build server can get the code for the website and the proper version of the core code. I'm using TFS & VS 2013 at the moment too, so there's that.
So, is there a way to do this that's straightforward, supportable/scale-able and intuitive? Thanks - Peter
Labels in TFS is very limited. For example once the label created you couldn't change and update it. If one of your core projects updated, did you need to create a new label for it. If you did and use the new label for one of your solution. However you found there are some bugs in this update, you need a newer update of your core project to fix the bug. Then a newer label created, you need to manually maintain the dependencies which seems not to be an easy job.
Moreover how to list the dependencies for your solutions based on TFS label names? TFS don't have this built-in option, seems the only way is store it in a txt or someother files and check in the source control. Every time the developer open a website application need to check it first and get label from server to their workspace and work on it.
Usually the purpose of sharing code between projects is reducing maintenance. There’s two main code sharing paths: source and binary. The difference between them you could take a look at this blog: Code Sharing in Team Foundation Server
Sharing code between products is a primary cause of quality erosion and elevated bug counts. I would recommend you to build separately and sharing binary output through NuGet which use preferable.
Also take a look below similar questions:
Sharing code between solutions in TFS
TFS 2010 Branch Across Team Projects - Best Practices
In most big enterprise application (Microsoft AX, NAV, SAP) normally the code migrates between different app scenarios: Development, testing, acceptance, production...
We develop with VisualStuido and TFS, and to achieve this we duplicate the database (production and test) and track our modifications manually, checking the TFS log, and generating manually a difference script between database versions, ...
Is it difficult to manage our main application lifecylce, deal with multiple micro-ALM with the customizations for each project/customer it is a lot of work!!
I found tools like Migrator.NET, but it is very manually. Is there a tool to implement this scenarios and track and migrate the changes automatically?
I don't know about 'automatically track changes' but from visual studio there is the menu 'Compare Databases' : http://msdn.microsoft.com/en-us/library/aa833435(v=vs.100).aspx
Maybe it could help.
You can easily compare database schema between servers using SchemaCrawler. SchemaCrawler is a free command-line tool that generates database schema details as text, in a format designed to be diff-ed, but at the same time be human-readable.
Sualeh Fatehi, SchemaCrawler.
I need somehow compare local version of pl sql package with the one that is stored in database. Are there any "easy" way to do it?
Currently I download package from database, save it in some file and perform diff using some diff tool. That is a bit cumbersome, so I would like to have such feature in ide (pl sql developer is preferable).
Typically developers use versioning software to check differences, maintain version history, and help coordinate team development of code. PL/SQL code should be no different. There's many ways to handle code releases, the following is just what I've seen done, not necessarily the "best" way.
In the Oracle environments I've seen, CVS or SVN is used. Most approaches involve checking out latest code from repository, editing (tagging/branching), and checking in. When code is tested (development instance) and release is ready, the DBAs either grab the release scripts from repository and apply, or one individual is tasked with handing over the correct release scripts to DBAs (more common from my experience). Note that the database here is typically a user acceptance instance that mirrors the production instance. If app testing passes, the code is promoted to production.
If you want to sync directly between the database and your IDE, the one option I've seen is Toad Team Coding. Toad is not free, and this option will require additional objects installed on the database (metadata/tracking tables, etc). A good overview is found here, and good setup article is found here.
Team coding is very cool, but I would only install on a development environment. How you promote the code from there through your system is up to you.
It's fairly easy to automate the procedure you described with a sqlplus command file. Select from all_source, spool it to a file. Invoke the diff command as "host diff ..." or "!diff ..." within the command file. The -b and -B options to diff will ignore whitespace and blank lines respectively.
I usually create a solution folder in Visual Studio and put my DB scripts in them. I always use at least this set of scripts:
Drop model
Create model script
User functions
Stored procedures
Static data (lookup tables)
Test data (not deployed)
Then I simply combine them and run against an SQL Server so I'm able to recreate the whole DB in a single step (by combining these scripts into a single one and executing it).
Anyway. I've never used projects in either:
Visual Studio or
SQL Management Studio
I've tried creating SQL Server 2008 Database Project in Visual Studio 2010, but I'm somehow overwhelmed by all the possible server settings (which I prefer to stay default as set on the server anyway). So I'm a bit confused: Should I use this project template or should I just do the same thing I always did?
What do you use and why? What are advantages I may benefit from by using either?
If I were you I would continue to do it the way you are doing it. In fact I do! The advantages of having the actual .sql files right there in a folder for you to use/edit/look at in my opinion are far better than the advantages you get by using a DB project. DB Project would be used if you were doing something like Storage Reports, were you have to communicate with like 8 databases and compare then to 8 different databases and save result sets etc... Now don't get my wrong there are advantages of Database Projects, I just don't think they are actually doing much help when you have such a simple setup that works already.
Advantages of the SQL Server 2008 Database Project in VS10:
Not having to switch back and forth
from your current client you use to
communicate with your SQL server.
Decent Data and Schema compare tools.
Gives you a one-click way to reverse
engineer a database into source
control, and keep it up to date.
You can compare projects to physical
databases and vice-versa. (This makes it pretty easy to keep your database up to date, no matter where you make change it: file system database project, or in the physical database itself)
If the current tool your using is not specifically tailored to SQL Server, this one is.
Extremely helpful if you need to do
unit tests directly on the database
without using abstractions.
If you're looking for something a little less complicated, you might want to try SQL Source Control. This won't even require you to maintain scripts, as it doesn't this for you behind the scenes. It will, however, only work as a solution for you if you use either TFS or SVN. And it costs $295...
It has a 28-day trial period, so if you're happy to try it out, I'd be interested in your feedback.