 | Liquid Rapid 8/22/2013 9:24:07 AM Yes! This would be great.
|
 | Kirill Bondar 8/22/2013 9:31:39 AM You can enable this is Setup > Database > Labs > Development Branch
|
 | anjuim moied 8/22/2013 10:05:30 AM I think this would also be very handy ,it would be amazing if you have you can have a number of databases that are updated from the single development branch.
|
 | Rick Cogley 8/26/2013 2:15:39 AM Interesting. Can I ask:
* can you specify what table you're working on (sharing)? Or if you set this, is it all tables?
* when does it get turned on: when you enable it in labs, or, is there another step?
* when email reminders, view subscriptions and triggers are DISabled, is this only in the dev branch, or, is it in the production as well?
Please advise.
|
 | Slava Shinderov 8/26/2013 2:52:33 AM @Rick,
> * can you specify what table you're working on (sharing)?
No, development branch is a separate snapshot of database settings that shares the data with production database.
> * when does it get turned on: when you enable it in labs, or, is there another step?
You'll be able to create/promote development branch via Setup/Database > Tools > "Create/Promote development branch" link.
> * when email reminders, view subscriptions and triggers are DISabled, is this only in the dev branch, or, is it in the production as well?
While creating a development branch system will perform following steps:
1.Remove roles from all users within development branch of database
2.Disable all e-mail reminders, view subscriptions, periodic and time-dependent triggers within development branch of database
|
| Rick Cogley 8/26/2013 3:58:27 AM Thanks. So it is not messing with production, only with the copy. That's going to work nicely.
|
 | Philipp Matuschka (MMB) 8/27/2013 8:18:51 AM Yes please, this is great news.
|
| anjuim moied 8/27/2013 9:57:51 AM are you planning to allow a database or many databases to be made from a development branch ?
|
| Kirill Bondar 8/27/2013 10:11:40 AM @Anjuim: DevBranch uses a copy of a application settings over single set shared data. Here the goal is to hide changes from the user until you've done with the work. We do not "synchronize" two apps while promoting changes - you can either accept all changes from devbranch overwriting changes in original app or can stay with original app.
What you need is to use one set of settings over multiple data copies, but I guess you would like to let your users make some changes in their apps. Such kind of synchronization would be quite different and far more complicated task since settings are closely interconnected.
|
 | martin oliver 8/28/2013 9:57:25 AM This would be very useful
|
 | basenine 8/28/2013 8:34:43 PM @Kirill,
When you say:
**We do not "synchronize" two apps while promoting changes…**
If users are working in the original app, adding data etc…when the DevApp is promoted, will the data be synchronised?
I only ask as it could be days worth of development and therefore days worth of data… If I go ahead and promote the DevApp, we obviously don't want to lose original data.
Cheers
|
| Rick Cogley 8/28/2013 8:57:51 PM Is the assumption not as follows:
* one set of shared data
* two sets of app configurations
* copy direction is only from the dev copy, to the master, overwriting the app configurations in the master
The implication being, anyone doing settings, would need to be making them in the dev copy only.
|
| basenine 8/28/2013 9:20:28 PM Is the Data from original not just copied at the start though? Then when in Dev mode, you're just using the data that was first issued…
I can check this - I've just made a Customer Record in Dev mode.
I'll see if it's gone through to the Original…
Yep - you're right. It's gone through to the Original App.
Whilst it's mentioned above:
**The branch is a copy of the original app; both sharing the same physical data. **...
I thought it would be just like Copying an application. Copying the Application ""share's"" the Data too - for the first part - then it branches off to two separate DB's…
Knowing this won't happen in Dev mode makes it a very useful tool.
Thanks Team TD!
@Rick - thanks for the pointer…I never assume anything these days though. Too much at stake to go down a path and have to redo because I thought incorrectly. Always best to cover bases, pre plan and predict proper outcomes. 😀
|
| basenine 8/28/2013 9:42:51 PM If you're a DB Flex user, I can also mention that there's no need to add a user licence for development. You can create the Dev mode, do as you wish and view everything you need to (both front end and back end) without disturbing anyone. Previously, I'd either need to kick someone off whilst developing or add a User licence…Adding the User licence was at the standard charge rate...
|
| Liquid Rapid 8/28/2013 9:46:12 PM Access to the user interface for development, without requiring a user license - that's a great benefit!
|
| Rick Cogley 8/28/2013 9:48:47 PM Yeah, assuming can be bad, and that really is a great benefit about the [no license needed.]
|
| basenine 8/28/2013 10:03:22 PM When using as a Developer and you're not logged into the original app, when you go into Dev mode, you'll need to assign yourself a role. You'll also notice that all the other users have been switched off - cool.
I'm currently working on two different apps at the moment for different customers…and no one's getting mad!! 😀
|
 | Scott Miller 8/29/2013 3:12:30 AM Hi guys, who has the ability to turn the Dev Branch on?
|
| Slava Shinderov 8/29/2013 3:17:51 AM @Scott anybody with "Full Access" setup permission.
|
| Scott Miller 8/29/2013 3:20:25 AM Ok so you could have a scenario where multiple Dev Branches are running?
|
| Slava Shinderov 8/29/2013 3:24:48 AM @Scott No, while setup link is available, system does not allow you to create more than one.
|
| Scott Miller 8/29/2013 3:25:35 AM Good stuff :-)
|
| Kirill Bondar 8/29/2013 4:15:01 AM @basenine, Rick: About "synchronization"
The data is SHARED between original app and the branch so from this standpoint there is nothing to synchronize.
The settings (formulas, views, documents, triggers and so on) are COPIED (except for users' roles and triggers disabled) when you create branch. When you promote the branch we re-assign roles and re-enable trigger based on original application's settings; then drop the original app and patch the branch to be available under original's app URL.
|
| basenine 8/29/2013 4:30:35 AM @Kirill,
Thanks for the verification. Are new Column Id's transported to the original app? or will they differ?
|
| Kirill Bondar 8/29/2013 5:21:07 AM Basically, the branch differs from production app by "-1" suffix in application id, all other ids are the same.
|
| basenine 8/29/2013 6:33:23 AM Thanks Kirill... That's what I thought
Cheers
|
| Kirill Bondar 8/29/2013 6:41:20 AM This stuff with keeping ids was significant change, if it will work well for branches we'll extend it to application copies.
|
| Liquid Rapid 8/29/2013 10:45:02 AM Keeping IDs across application copies would be useful for me, Kirill. Especially if it keeps the view filter IDs. I have a functionality in one app that depends on view filter IDs. Every time the admin deploys the app to a new subscriber, they have to go through and update for the new IDs manually. If the IDs stayed the same, that would make deploying much easier.
|
| basenine 8/29/2013 4:54:12 PM @Nathan... I think the Id's only stay the same for the DEV mode not on a copied version. It sure would be good if they could though but I think a column can only be related to one application id
|
| basenine 8/30/2013 12:01:00 AM |
| martin oliver 8/30/2013 2:13:04 PM If a development branch has been created and setup changes are made in the main application do these changes automatically sync with the development branch
|
| Slava Shinderov 8/30/2013 2:19:22 PM @Martin No, moreover they will be lost when you will promote development branch.
|
| martin oliver 8/30/2013 3:17:04 PM If a development branch has been created and you decide not to use it, can it simply be deleated
|
| Slava Shinderov 8/30/2013 3:18:20 PM Yes
|
| martin oliver 8/30/2013 3:19:43 PM Thanks Slava
|
| basenine 8/30/2013 3:56:53 PM @Kirill…+1 for this <"This stuff with keeping ids was significant change, if it will work well for branches we'll extend it to application copies."> This will null the necessity for my request Column and View Id's easily visible |
| martin oliver 8/30/2013 3:59:24 PM This could be a bit messy when there is more than one person doing setup's. Also small setup changes may be required in the main application while in the process of major changes in a development branch which is still a work in progress
|
| martin oliver 9/3/2013 12:52:13 PM @Kirill said
"When you promote the branch we re-assign roles and re-enable trigger based on original application's settings; then drop the original app and patch the branch to be available under original's app URL."
If you delete the development branch and do not promote it - what happens the the disabled triggers?
|
| martin oliver 9/3/2013 12:53:47 PM Or are the triggers only disabled in the dev branch?
|
| martin oliver 9/3/2013 1:43:17 PM After Dev branch created, newly created triggers in main branch don't seem to activate, although they can be created?
|
| Kirill Bondar 9/3/2013 3:35:46 PM @martin: original app is left intact; dev branch is its almost exact copy with users/periodic and time-dependent triggers initially disabled. You can enable triggers back in dev, though you should understand that they are running over shared data and both the original trigger and its copy will run for the same record. It's not a big harm if trigger merely sends email alert, but if it increments some counter you might be surprised. That's the background of an idea to disable triggers: we are trying to prevent tricky situations; you are free to do what you want but you take the risk.
|
| martin oliver 9/3/2013 5:08:22 PM @kirill
Thanks I think understand - so you will get two (i.e. record create triggers). One from the main & one from the dev branch. This would be a problem for us as we have many workflow triggers creating new records.
|
| Kirill Bondar 9/3/2013 5:54:59 PM @martin: change triggers are OK as they are triggered as the result of user interaction. An application you create the record through runs its own trigger, other app's trigger won't run. In contrast, periodic and time dependent triggers could pose a problem. Suppose you set up daily trigger to create a record. After making a branch you will have two daily triggers (if not disabled) that run over shared set of data, creating 2 records every day.
|
| basenine 9/3/2013 5:59:41 PM When creating a record in the DEV branch, can it be flagged with something to highlight it's creation source?
Then when cleaning up, we could create views that only show the DEV created records... Mass delete them... Yada yada yada
|
| martin oliver 9/4/2013 10:16:29 AM @kirill
Would it not make sense for periodic triggers to still run in the main branch but be disabled in the dev branch only, where the data is still the same as it syncs between the two.
|
| Kirill Bondar 9/4/2013 10:51:28 AM @martin: it works exactly as you described
|
| martin oliver 9/4/2013 10:59:51 AM @kirill
Thanks, the question arose when I could not get a periodic trigger to function with a dev branch enabled, or so I thought, because as soon I deleted the dev branch the trigger worked. May have been something else I guess
|
| Kirill Bondar 9/4/2013 4:51:39 PM @martin: the order periodic and time dependent triggers are executed is indeterminate. One case could be that branch's trigger modifies the record so it does not pass the filter when original app's trigger runs.
|
| basenine 11/6/2013 2:16:23 AM Hello Slava, et al...
I just created a development branch and the email notifications were not turned off... I just received a batch of 200 emails - in one click.
I used the "Send Feedback" link to let you know. That sends me here. Not sure if that's what you're intending with the "Send Feedback" link.
Kind regards - Brett
|
 | Joshua Mullins 11/14/2013 3:53:20 AM Hi Guys, Is it possible that the owner of the Dev Branch could be changed to the user who created it rather than the original application owner?
There doesn't seem to be any harm in deleting the Dev branch if only one user can create one at a time.
|
| Joshua Mullins 12/16/2013 2:23:57 PM After creating a dev branch, we encounter the following error on every table until save has been pressed many times and this is not the first time it has happened...
'Cannot insert duplicate value "TMID-432144" into column "Time Id"'
Please can the Dev Branch functionality be fixed so that this does not happen again.
|
 | Gii Systems 1/23/2014 2:09:04 AM I am trying to make a column "Unique" in my db, and get the following error:
DEVBRANCH: Cannot modify shared column's uniqueness
|
| Kirill Bondar 1/23/2014 5:27:11 AM Requiredness and uniqueness are controlled on a physical database level. Since both original app and development branch are sharing the same physical database you can not modify requiredness and uniqueness of columns in tables shared in both apps. However, there are no restrictions for tables created in the devbranch.
|
| basenine 7/26/2016 7:22:14 PM Because the ONLY references to the fact that a DEV branch is being worked on reside at the Header (as "DEV", highlighted in red) or in the browser URL address bar (appID-1), it is easy to mistakenly work in (or demonstrate) the wrong Application when you've scrolled down past the header. If the HEADER could remain fixed (like mentioned here: Make header on page non-scrollable and here: Tabs and Sidebar to be fixed in position when scrolling) the "DEV" could be more readily viewed and therefore stand out more. This one small tweak (fixing in place...non scrollable) to the header (where USER, SUPPORT and SETUP reside) would help to eliminate this issue. And also provide the benefits discussed in the referred ideas |
 | Patricio Bustos 9/3/2016 9:31:17 AM I've been testing this functionality but there are things I do not understand:
1. Data are shared between the production database and development. That is normal? For example, I think test data in the development environment, and these are displayed in the production environment.
2. Users still have access to both databases. That is normal?
Please if you help me clarify these doubts.
|
| Kirill Bondar 9/3/2016 12:00:49 PM @Patricio
1. It's by design of the feature. Would we create development branch with the copy of real data, it would be impossible to propagate the changes that involve data transformation such as moving the list of choices off the column to separate table and replacing column with choices with reference column, the data will change. That's you want to have test data that should not be promoted back, but in some cases you need to propagate changed data back to production. This would be a mess. Just remember the data is shared, so if you want to test editing, create a test record.
2. User who created the branch for sure has access to it. Other users in development branch are disabled - they have no role and therefore no access, you'll have to enable other users explicitly.
|
| Slava Shinderov 6/13/2017 7:27:11 AM |
