We have all had that issue with the Repository or the Orchestration Engine being unable to get to the gsoap web service URL. And, this is with all SBM components installed on the same server. Why can't it get to itself? Or in the case orchestrations, maybe we cannot figure out why the OE is unable to reach a third party web service.
Continuous Delivery (CD) is a software engineering approach in which teams produce software in short cycles, ensuring that the software can be readily released at any time. Continuous Delivery is enabled through a deployment pipeline that breaks down the software delivery process into stages, with each stage verifying the quality of new features from multiple perspectives including the prevention of errors, findings and security vulnerabilities from impacting end users. The pipeline should provide rapid feedback to the team and visibility into the flow of changes to everyone involved in delivering the new features.
There is typically no such thing as a standard pipeline, in part as applications are very different in terms of architecture, technologies and complexity, but a typical CD pipeline will include the following: build automation and continuous inspection, test automation, and deployment automation.
Build automation and Continuous Inspection
The pipeline starts by automating the building of binaries to create the release deliverables that will be passed to the subsequent stages. New features implemented by the developers are integrated into the central code stream on a continuous basis, built and continuously inspected. This provides the most direct feedback cycle that informs the development team about the health of their application code through evaluating the results of builds, unit tests, source code analysis tests, web vulnerability tests and open source policy violations – automating a configurable continuous inspection toolchain provides rapid feedback to the developers where they need it, and also aggregates metrics to assess readiness for test and deployment automation.
The new version of an application is then rigorously tested to ensure that it meets all desired system qualities, ensuring that functionality, security, performance or compliance — are verified by the pipeline. The stage may involve different types of automated or (initially, at least) manual activities.
A deployment is required every time the application is installed in an environment for testing, but the most critical moment for deployment automation is production rollout. Since the preceding stages have verified the overall quality of the system, this can be a low-risk step. The deployment can be staged, with the new version being initially released to a subset of the production environment and monitored before being completely rolled out. The deployment is automated, allowing for the reliable delivery of new functionality to users within minutes, if needed.
The deployment pipeline is usually supported by platform provisioning and system configuration management, allowing teams to create, maintain and tear down complete environments automatically.
Where multiple stages in a deployment pipeline involve collaborative groups who oversee and track the progress though any necessary approvals and delivery, orchestrating the release process provides a high level view of the entire pipeline, supporting the ability to define and control the stages, and monitor insight into the overall software delivery process.
Recommendations for achieving Continuous Delivery
For most organizations it may not be feasible to adopt Continuous Delivery all at once, and a better approach is to focus on identifying the prioritized bottlenecks and improving each of them in the delivery process as you continue to iterate and measure improvements.
Here’s an example of a Continuous Delivery Pipeline process
On 25th February, 2017, certificates that Serena|Micro Focus used to sign Java applets provided by PVCS Version Manager and Dimensions CM expire
When opening the Web client for PVCS and the Web client or Admin console for Dimensions CM, if the Java Runtime Environment (JRE) displays a certificate acceptance dialog, there will be a an additional message on that dialog indicating that the certificate is still valid but has expired, similar to:
The certificate used to identify this application has expired.
To solve this problem, users will need to do one of the following:
- Users of Dimensions CM 12.2.2, 22.214.171.124, 14.3.1 or 14.3.2 should install the updated applet files available from KB Doc P2787.
- Users of VM 8.5.3 should install VM 8.5.3 Patch 004. This patch is available from KB doc P2786.
- The recommended solution for users of older VM 8.5.x releases is to first install the VM 8.5.3 patch, available from KB doc P2757, then install VM 8.5.3 Patch 004.
- The recommended solution for users of pre-VM 8.5 releases is to first upgrade to VM 8.5.0, then install the VM 8.5.3 patch and finally install VM 8.5.3 Patch 004.
- If circumstances prevent you from installing VM 8.5.3 Patch 004, you can use KB doc P2788 to obtain a re-signed applet for VM 8.4.6 ComboHotfix 1 through VM 8.5.2.
- Until the patch can be installed, you can do one of the following:
- Add the server URL to the Exception Site List in Java Control Panel (Control Panel -> Java : Security)
- Press "I accept the risk and want to run this application".
If you have any questions, please contact technical support.
The Dimensions CM Git Connector allows for disparate Git repositories to be bought under a centrally controlled highly secure repository by storing code into Dimensions CM streams.
This tutorial will cover a typical multi-developer merge scenario using the Git Connector.
The attached PDF document covers the following steps:
Step 1: Download and Install Git
Step 2: Configure Git
Step 3: Clone a stream using the Git Connector
Step 4: Modify the existing repository
Step 5: Add the new file and commit the changes to the Git repository
Step 6: Use the push command to commit Git changes into Dimensions CM
Step 7: Make another change in the Git repository but do not push it back to CM
Step 8: A second developer delivers a modification to the stream
Step 9: Use the push command to attempt to commit the Git changes back into Dimensions CM
Step 10: Resolve the conflict by performing a git-dm pull
Step 11: Review the changes and deliver the merged Git repository into CM Debug information Further Information
Click the attached PDF document for more information.