Other strategies for promotion management?

[Former Member]

Having read this blog post on object migration, I am wondering if there are any alternative strategies?

It is somewhat tedious to have to go through so many steps to move changes from development to production with Designer. You have to do the following if you make a change (or bugfix on production process):

1. Make change on local dev repo
2. Check into devcentral
3. Reopen designer, connect to local test repo
4. Pull to local test repo
5. Check into testcentral
6. Reopen designer, connect to local production repo
7. Pull to local prod repo (now live)
8. Check into production central

I understand you can bypass the checkin steps (2,5,8) and directly move objects from local repo to other local repo, but this bypasses all the standard version control. Is there any way to prevent this (and require objects to go through the central repository check-in process)?

[former_member185603 · Accepted solution]

if you want to follow SDLC, you need to follow the steps described in the blog. But many scenarios, we may need to follow some shortcut paths, espicially if we have to make production changes, urgent issues. 

[Former Member · Accepted solution]

Thank you for the reply!

That's exactly the situation I am concerned with, if the process we have is the full SDLC process then anytime there is any urgent or production down type of issue we have to bypass the entire process to make the changes.

[Former Member]

Hello

Yes, there are alternative strategies.  I am not keen on multiple central repositories (across the landscapes), they introduce too much complexity and really aren't required.  Consider a software company, they use a single repository for their releases, why should Data Services code be any different?

A single central repository under the development environment is all that's required, with a responsible person to build and label releases.  A local repository in the development environment is used to assemble release candidates (using the central repo); package it with other artifacts (SQL, etc.) then pass this to other environments, first QA, then if it passes testing, the release can go to production.

The Data Services documentation has unfortunately given people ideas that are too complex for moving code across environments.

As for system and datastore profiles, they are intended to allow jobs to be executed against various sources and targets (for example load US, then UK sources into a common target), not to cross the system landscape.  I mean, what sort of organisation would put production credentials anywhere other than production?!  (Although they can be useful in non-prod to load data across the landscape, QA into dev for error diagnosis.

Setting up robust procedures is not easy, but it does help for an easy life in the future.

Michael

[Former Member]

After reflecting on this, your post gives me a lot of other potential ideas. I come from a software development background and so for me the idea of having three concurrent and likely different repositories for the same data is something I don't really get too excited about.

In a setup like that, would you have a "release" and a "dev" branch? In software dev you'd do something like this - have a branch for active development and then a default/master branch you use for releases. Or just use labels on the commits so you know when you release.

It seems to make the most sense to use the "label" feature for this in DS with the checkins? It seems that you only check in objects which change, which is rather annoying as there is no way to do a standard "commit history" at the project level (that I can tell at least).

It also seems that DS doesn't allow you to checkout the project and then update to an older commit. Is there any way to do this easily? It looks like you can get the older object, then export it and then once you checkout the latest version you could replace it via importing?

This was very helpful!

[Former Member]

You asked "It also seems that DS doesn't allow you to checkout the project and then update to an older commit. Is there any way to do this easily?"

Yes, but use with caution!  Get the older version of the objects you require into your repository, then perform a checkout without replacement, then check-in.

Michael

[Former Member]

Ah! So that's what the "without replacement" checkout refers to. The language wasn't clear to me.

Thank you again. I think I really, really like the idea of using a single central repository. It seems like this is by far the best way to keep version history while also ensuring only one person is working a project at any given time (regardless of prod/test/dev).