Software deployment is all of the activities that make a software system available for use. The general deployment process consists of several interrelated activities with possible transitions between them.
In this series of articles, I'd like to present and discuss several possible approaches toward software development with InterSystems technologies and GitLab. I will cover such topics as:
In this series of articles, I'd like to present and discuss several possible approaches toward software development with InterSystems technologies and GitLab. I will cover such topics as:
Git 101
Git flow (development process)
GitLab installation
GitLab Workflow
Continuous Delivery
GitLab installation and configuration
GitLab CI/CD
In the first article, we covered Git basics, why a high-level understanding of Git concepts is important for modern software development, and how Git can be used to develop software.
In the second article, we covered GitLab Workflow - a complete software life cycle process and Continuous Delivery.
In this series of articles, I'd like to present and discuss several possible approaches toward software development with InterSystems technologies and GitLab. I will cover such topics as:
Git 101
Git flow (development process)
GitLab installation
GitLab Workflow
Continuous Delivery
GitLab installation and configuration
GitLab CI/CD
In the previous article, we covered Git basics, why a high-level understanding of Git concepts is important for modern software development, and how Git can be used to develop software. Still, our focus was on the implementation part of software development, but this part presents:
GitLab Workflow - a complete software life cycle process - from idea to user feedback
Continuous Delivery - software engineering approach in which teams produce software in short cycles, ensuring that the software can be reliably released at any time. It aims at building, testing, and releasing software faster and more frequently.
I'm using Git with DeepSee and when I need to do a commit to the git repo I'm exporting ALL the pivots and dashboards from the namespace. But I can forget to do that) And it can take time for a large system.
What is the way to manage automatical export of DeepSee artefacts which we are editing in UI (Cubes, Pivots, Dashboards, Pivot Variables, Term lists, Shared Measures) into files every time when I push Save button?
Some people are lucky enough to have a totally separate environment to run production in.
-- Unknown
.
In this series of articles, I'd like to present and discuss several possible approaches toward software development with InterSystems technologies and GitLab. I will cover such topics as:
Git 101
Git flow (development process)
GitLab installation
GitLab WorkFlow
GitLab CI/CD
CI/CD with containers
This first part deals with the cornerstone of modern software development - Git version control system and various Git flows.
I have been playing around with the Management Portal deployment tool, which involves: Ensemble > Manage > Deployment Changes > Deploy and Production Settings > Actions > Export Production Settings > Actions > Re-Export
Everything was going fine , until I came across this:
The Installer Manifest has the option to modify the production level settings for AutoStart but is there a way to change settings such as ActorPoolSize and other settings? What would the format be to change such a setting to change the ActorPoolSize to 2?
I'm trying to write an installer manifest that can create a namespace, resources (%DB_namespace) and a role (with the resource, above), based on the namespace. So you could pass in "ABC", or "XYZ", and it would create the %DB_ABC resource and the ABC role with %DB_ABC:RW permissions; or it will create the %DB_XYZ resource and the XYZ role with %DB_XYZ:RW permissions, accordingly.
I just deployed my production from test to acceptance but I found that the deployment misses some Soap Webclient classes which are used by my business operation components. I have used the management portal to create the deployment (i.e. production settings -> Export) and I expected that all classes used by the production were automatically included. Apparantly, that is not the case. Is this default behaviour for Ensemble? And can I somehow force Ensemble to automatically include these classes?
If you have an app that uses some Caché client Windows components that are not included into CacheODBC distribution (e.g. CacheActiveX.dll), you need to proceed Caché client installation on end user's client computers and/or MS Terminal Servers. Being a part of Caché client's installation, Caché Cube is installed along with other components and is autostarted with every user's session. So, it becomes visible to every user.
To make it completely invisible, you can just move CACHE.lnk file from
Last week saw the launch of the InterSystems IRIS Data Platform in sunny California.
For the engaging eXPerience Labs (XP-Labs) training sessions, my first customer and favourite department (Learning Services), was working hard assisting and supporting us all behind the scene.
Does anyone have experience using SCCM or any other enterprise application management tool to deploy updates to a thick client (internally developed standalone app) across the enterprise? I have a client that is attempting to get this working for their customer and running into some trouble. If you have any knowledge or experience you can share it would be greatly appreciated.
I have read some MS Technet pages that appear to indicate this is possible
Is it possible to save Cache code into a file and then run it via command line?
IE: csession [ini] -U [ini] /path/cacheCodeFile.?
What I need to do is run a Cache script from the Linux command line. The script will navigate data to produce a file and then it will exit back to the command line.
I'm exploring using installation manifests to deploy Ensemble configuration changes. I noticed that the documentation uses a macro within an "Error" tag.
<Error Status="$$$NamespaceDoesNotExist">
So I thought this would also be possible with "Var" tags, "If" tags, etc. For example:
Configuring an Ensemble production can be a challenging task involving a thorough understanding of the system and production functionality and a detailed understanding towards each configuration item. After successfully configured an Ensemble production, you might need to set up an identical production on the mirror environment, or deploy the production on a development system to a live system, or send a copy for diagnostic/debug purposes. Other times you might have spent some time designing a BPL/DTL and some other productions can use the same logic.
Due to a new project I'm getting involved inside %Installer stuff deeper than ever I'd be happy to. Most of it was pretty easy to get, thanks to documentation, articles and SAMPLES example, while I can't dig good solution for one problem.