Best practice synchronize libraries development / production
We are running RAFW 7.1.2 which we use to install and configure our three WebSphere environments (test, qa, production), each WAS-environment being represented by a project in Buildforge, all using the same library defining the deployment process, using Buildforge environments to differentiate between the WebSphere environments (servernames, nodenames etc, etc).
But now before handing the Buildforge/RAFW over to operations, we need to create a Buildforge test environment, where we can have a test version of the main BF-library. In that way we can change existing steps and/or add new and delete existing ones according to new needs, test them and when verified synchronize the changes with the production library. Currently Im not aware of any functionality to synchronize libraries in Buildforge apart from doing it manually, which isa bit risky if you ask me. Any good suggestions on how to best solve this issue? In advance |
2 answers
We are running RAFW 7.1.2 which we use to install and configure our three WebSphere environments (test, qa, production), each WAS-environment being represented by a project in Buildforge, all using the same library defining the deployment process, using Buildforge environments to differentiate between the WebSphere environments (servernames, nodenames etc, etc). anytime you have manual interaction in a process it risks human error. Buildforge does not have the concept of peer servers or any way to automatically sync projects or libraries to another server. I would suggest creating the process to do what you need, and then creating a BuildForge project to do those steps. You're looking at bfexport, scp (or other data transfer mechanism), and bfimport (using the replace option I suspect). Make sure you keep your old export files around for rollback should you determine there is a problem. Creating a datestamp based name early in the project and using an env var to store and access that name is a good idea. |
...I would suggest creating the process to do what you need, and then creating a BuildForge project to do those steps. You're looking at bfexport, scp (or other data transfer mechanism), and bfimport (using the replace option I suspect). Make sure you keep your old export files around for rollback should you determine there is a problem. Creating a datestamp based name early in the project and using an env var to store and access that name is a good idea. When realizing that bfexport of projects also includes libraries a solutions as described by rhaig will be just what we need. Since we also use subversion, keeping history of changes is no issue - we would just export the project definitions to a XML-file. Then copy the content of the whole development library tag to the production library tag (renaming the name attributes off course) and then import it to Buildforge. This is also confirmed by IBM Support as currently the only solution to do this (Maybe you could do the same thing in the database, but you would not have version control using Subversion then, so this was not an option to figure out) Problem solved, thanks! |
Your answer
Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.