I am relatively new to BODS and trying to figure out how to, and the good practices in doing things.
I am working at a client who has at most 3 developers and do not have central repo yet. Each developer has a local repo and a local repo for each environment (dev/QA/Prod).
We are looking at using the central repo for code sharing, migration and version control. To begin with we prefer just one central repo.
I want to know couple of things -
How do we migrate a change (multiple objects) as a bundle across repos (local to central to local)? Similar to ATL, but how to do that in central repo without losing the versioning?
I am okay for the developer to migrate individual change objects one time, and there after the administrator moves as a bundle (or minimal effort) instead of having to deal with objects individually.
Is there a way to backout/rollback a change in central repo?
It seems labeling may help do what i am looking for, but I couldn’t quite figure out how yet.
Please give me some guidance and any good practices in general for migration. All help is appreciated.
This is a good way to go. In my opinion a single Central Repository is easier to administer. Just make sure the developers don’t check objects in after every little change. Check objects in when a set of changes are complete and have been tested in their own local repository.
There is supposed to be a mass migration tool coming in 4.Something. I don’t think it is available yet so you have to do migrations object by object.
Still has to happen object by object. You could do a GET from the Central Repository and use the With Dependents option. But I recommend against this because:
The latest version in the Central Repository may not be the version that was tested.
If you aren’t careful you can over-write objects that you do not want that to happen to. Specifically, this refers to Datastores which should be migrated to an environment ONCE and ONLY once.
No. You have to make a new version or delete the entire object.
Labels are good way to go. However, there is no way to do something like GET all objects with a label of “Prod_20130505”. At least not yet.
You can still use the ATL migration method to do things in batch and I’ve used this with good results. But you have to use a scratch local repository to GET objects into and then export those objects from that repository. This technique makes it possible to prepare a large number of objects for migration and then finalize the migration (using Import from File) in just a few seconds with less chance of making a mistake.
I have read some of your posts on this forum. You and couple other members provide very valuable input here.
From what I see/hear so far, i will have to just go by object.
Exploring Labeling, I realized that in BODS4.0 there is now a filtering option in it. This is useful.
I only wish they had an export to ATL feature for the Get functions.
If you have worked with one of the enterprise version control tools you know how much functionality Data Services is missing from the Central Repository. They are working on it, but it will take time.
If you have direct access to the Central Repository database there is a way to apply labels using SQL. When I had a migration of over 300 objects I decide there was no way I was going to sit there and label that many objects.
I am working in a BODS 4.0 environment and am trying labeling for the central repository, however when we migrate our changes and labeliong from Dev central repository into our QA central repository it seems as though the labeling is lost?
Thanks for the quick reply Jim!
We have a Dev and a QA central repository for several years now (just getting into labeling…). We tested and seems like we just have to re-label in the QA central repository. Not the best, but it is better than not having any option for recovery. Currently we use atl backups…
Thanks again Jim!
Take care.
Thanks for the good discussion here. I have an additional question which I think is a good follow-up to this thread, so I’ll post it here instead of starting a new thread (if that’s okay).
We have gone to a single central repository (CR) model, but I sometimes check things into it even though they are not ready to migrate to production, such as when we begin testing, or just if I have to put that project aside for a while and want to make sure what I have so far is saved somewhere other than my local development repository, and for history tracking.
But we sometimes have confusion over what versions should be in the production local repository (LR) or not. Personally, I’ve been tracking this by labeling the CR versions that I migrate to the production LR with a label like “Migrated mm/dd/yy Brooking”, but this is not an official policy, and not all the developers do it. (I seem to be the most conscientious about version control, and our manager doesn’t get involved in it.) I’d like to suggest it be universally adopted, and to develop a repository query that would return the list of versions that should currently be in production, using these labels, so we have a way of knowing what should be in the production LR, without having to maintain a separate list like an Excel spreadsheet, because that would be more work, therefore less likely to be maintained.
Problem is that all the rows I find in the CR respository’s AL_LANG table have a LABEL column value of NULL. So I’m not sure where to find the labels that I’ve already applied. Anyone have any insight into this? Do I need to look in another table? Thanks in advance.
Update, next day: Never mind, I figured it out. It’s the AL_LABEL table. I thought I had already checked that, but probably I had accidently checked it in the production local repository, which of course is empty. They are all there in the central’s AL_LABEL table.
John, taking your thoughts to the next step, which would be automated builds, would require a very disciplined development group and some custom programming as well as a lot of command line processing.
After checking in an object for migration the developer would have to enter a tightly controlled label. A label as simple as the date (in an agreed upon format) would work. For example, 20140915. Any items with a label of that value and lower would go into today’s build. There would have to be some filtering to ensure that you’re dealing with only the most recent labels.
You not only want the objects in AL_LANG! The AL_LANG table is the central table for labeling of all objects, but not all objects (tables are one example) are in AL_LANG. Once you find an object’s label in AL_LABEL you then have to find the proper table that the object itself resides in. The object type is in AL_LABEL so you may be able to skip this step.
Once you have a list of objects (and their type and version) to be migrated you can call the AL_ENGINE command to export each object from the Central Repository. The problem here is that the AL_ENGINE command has no way (that I could find) of exporting a specific version of an object. You can get the source code directly from where the object resides (such as AL_LANG/AL_LANGTEXT), piece together the individual rows and then write it to a file.
I wrote an application in PowerBuilder quite a few years ago to export each object to individual files. It wasn’t hard once you understood the repository table relationships.
(BOB member since 2007-09-12)
(BOB member since 2007-09-12)