Everybody has a testing environment.

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 am pleased to announce the availability of InterSystems Container Registry. This provides a new distribution channel for customers to access container-based releases and previews. All Community Edition images are available in a public repository with no login required. All full released images (IRIS, IRIS for Health, Health Connect, System Alerting and Monitoring, InterSystems Cloud Manager) and utility images (such as arbiter, Web Gateway, and PasswordHash) require a login token, generated from your WRC account credentials.

In the vast and varied SQL database market, InterSystems IRIS stands out as a platform that goes way beyond just SQL, offering a seamless multimodel experience and supporting a rich set of development paradigms. Especially the advanced Object-Relational engine has helped organizations use the best-fit development approach for each facet of their data-intensive workloads, for example ingesting data through Objects and simultaneously querying it through SQL. Persistent Classes correspond to SQL tables, their properties to table columns and business logic is easily accessed using User-Defined Functions or Stored Procedures. In this article, we'll zoom in on a little bit of the magic just below the surface, and discuss how it may affect your development and deployment practices. This is an area of the product where we have plans to evolve and improve, so please don't hesitate to share your views and experiences using the comments section below.

In this series of articles, I'd like to present and discuss several possible approaches toward software development with InterSystems technologies and GitLab.

It is with great pleasure that the CIUSSS de l'Estrie - CHUS is sharing the mocking framework it developed and presented at the InterSystems Summit 2017.  I will update this post with more detailed instructions in the next few weeks but I wanted to share the code and presentation quickly : 

https://gitlab.com/ciussse-drit-srd-public/Mocking-Framework

I hope you'll find this useful for your unit testing. We are using this extensively for the last 2 years and it really works well! The repo is public, feel free to submit enhancements!

Do not forget to enable the %UnitTest in your SMP.

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
• Why containers?
• Containers infrastructure
• CD using containers

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 the third article, we covered GitLab installation and configuration and connecting your environments to GitLab

In the fourth article, we wrote a CD configuration.

In the fifth article, we talked about containers and how (and why) they can be used.

In the sixth article let's discuss main components you'll need to run a continuous delivery pipeline with containers and how they all work together.

In this article, we'll build Continuous Delivery configuration discussed in the previous articles.

Hi Community!

We're pleased to announce that that InterSystems IRIS Community Edition is available on the Docker Store! InterSystems IRIS Community Edition is the no-cost developer edition designed to lower the barriers to entry to get started with IRIS. Now that it is listed on the Docker Store, running an IRIS Community instance is as easy as -

For more on running IRIS in containers check out our Documentation or one of the many Community posts on the topic!

I would say it is a post of pain after years of using InterrSystems IRIS Docker images in many projects.

And I hope InterSystems will hear me and do something with it.

We have a lot of issues with Docker images, but I see no progress in solving them.

• containers.intersystems.com - any new releases substitute previous versions, makes build useless
  • ARM64 images have separate names, and it makes a pain to use them
• flags in iris-main, appears and disappears from version to version, which may fail the start the container
• healthcheck does not work as expected

IRIS configurations and user accounts contain various data elements that need to be tracked, and many people struggle to copy or sync those system configurations and user accounts between IRIS instances. So how can this process be simplified?

In software engineering, CI/CD or CICD is the set of combined practices of continuous integration (CI) and (more often) continuous delivery or (less often) continuous deployment (CD). Can CI/CD eliminate all our struggles?

I work in a team which develops and deploys IRIS clusters. We run IRIS in containers on Red Hat OpenShift container platform.

When you deploy code from a repo, class (file) deletion might not be reflected by your CICD system.
Here's a simple one-liner to automatically delete all classes in a specified package that have not been imported. It can be easily adjusted for a variety of adjunct tasks:

set packages = "USER.*,MyCustomPackage.*"
set dir = "C:\InterSystems\src\"
set sc = $SYSTEM.OBJ.LoadDir(dir,"ck", .err, 1, .loaded)
set sc = $SYSTEM.OBJ.Delete(packages _ ",'" _ $LTS($LI($LFS(loaded_",",".cls,"), 1, *-1), ",'"), "/generated=0", .err2)

The first command compiles classes and also returns a list of loaded classes. The second command deletes all classes from specified packages, except for the classes loaded just before that. Any generated classes are also skipped since they won't be in the loaded list.

This article will describe processes for running unit tests via the InterSystems Package Manager (aka IPM - see https://openexchange.intersystems.com/package/InterSystems-Package-Manager-1), including test coverage measurement (via https://openexchange.intersystems.com/package/Test-Coverage-Tool).

Unit testing in ObjectScript

There's already great documentation about writing unit tests in ObjectScript, so I won't repeat any of that. You can find the Unit Test tutorial here: https://docs.intersystems.com/irislatest/csp/docbook/Doc.View.cls?

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.

Welcome to the next chapter of my CI/CD series, where we discuss possible approaches toward software development with InterSystems technologies and GitLab. Today, we continue talking about Interoperability, specifically monitoring your Interoperability deployments. If you haven't yet, set up Alerting for all your Interoperability productions to get alerts about errors and production state in general.

Inactivity Timeout is a setting common to all Interoperability Business Hosts. A business host has an Inactive status after it has not received any messages within the number of seconds specified by the Inactivity Timeout field. The production Monitor Service periodically reviews the status of business services and business operations within the production and marks the item as Inactive if it has not done anything within the Inactivity Timeout period. The default value is 0 (zero). If this setting is 0, the business host will never be marked Inactive, no matter how long it stands idle.

The Widgets Direct sample application highlights many aspects of how to use InterSystems technologies to build a modern web application.

For quite some time InterSystems IRIS supports such thing as Merging CPF. So, with help of this it should be possible to define only desired changes in configuration. And get them applied even with vanilla Docker image. 

And I though it could be useful when used with Dockerfile. Use this way to configure IRIS during docker build instead of using Installer manifest.

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
• Why containers?
• Containers infrastructure
• CD using containers
• CD using ICM
• Container architecture

In this article, we would talk about building your own container and deploying it.

Welcome to the next chapter of my CI/CD series, where we discuss possible approaches toward software development with InterSystems technologies and GitLab.

Today, let's talk about interoperability.

Issue

When you have an active interoperability production, you have two separate process flows: a working production that processes messages and a CI/CD process flow that updates code, production configuration and system default settings.

Clearly, CI/CD process affects interoperability. But questions are:

• What exactly happens during an update?
• What do we need to do to minimize or eliminate production downtime during an update?

Hi All,

Who, in the age of digital transformation, doesn't want to reap more benefits out of any process, procedure, and resource we have? At InterSystems Solution Developers Conference (part of InterSystems Global Summit 2018) we will have sessions on how to improve the way applications are built with modern tools like Docker containers, Gitlab, Circle CI, Travis, etc., how continuous integration and continuous delivery (CI/CD) processes can help us deliver more value quickly to the end-user, and how we can start thinking about modernizing traditional applications.

Such most popular nowadays CI platforms as GitHub and Gitlab, offers the ability to run any docker image as a service, mostly useful for integration tests.

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
• Why containers?
• GitLab CI/CD using containers

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 the third article,  we covered GitLab installation and configuration and connecting your environments to GitLab

In the fourth article, we wrote a CD configuration.

In this article, let's talk about containers and how (and why) they can be used.

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
• Why containers?
• Containers infrastructure
• GitLab CI/CD using containers

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 the third article, we covered GitLab installation and configuration and connecting your environments to GitLab

In the fourth article, we wrote a CD configuration.

In the fifth article, we talked about containers and how (and why) they can be used.

In this article let's discuss main components you'll need to run a continuous delivery pipeline with containers and how they all work together.

Just curious how many companies use in their work Docker containers, I mean not only with InterSystems products. And if such companies exist, which of them uses docker and doesn't  use it for InterSystems products  by some reasons. What are the reasons? For companies which already uses InterSystems in containers, how do you use it? Development environment, testing or even in production ?

And if you don't use but thought about it, what are the reasons which stop you.

This is a continuation of my story about the development of my project isc-tar started in the first part.

Just having tests is not enough, it does not mean that you will run tests after all changes. Running tests should be automated, and when you cover all your functionality with tests, everything should work well after any change in any place.  And Continuous Integration (CI) helps to keep the code and deployment procedure with as fewer bugs as possible and automates the routine procedures, like publishing releases.

I use GitHub to store the source code. And some time ago GitHub started to work on its own CI/CD platform and named it GitHub Actions. It is not widely available, yet. You have to be signed as a beta tester for this feature, as I did. GitHub Actions uses quite a different way how to deal with a build workflow. What is important that Github Actions allows to use Docker, and it’s quite easy to customize available actions. And interesting that GitHub Actions is really much bigger than any classic CI like we have in Travis, Circle or Gitlab CI and so on. You can find more in the official documentation.

Keywords:  IRIS, IntegratedML, Flask, FastAPI, Tensorflow Serving, HAProxy, Docker, Covid-19

Purpose:

We touched on some quick demos of  deep learning and machine learning over the past few months, including a simple Covid-19 X-Ray image classifier and a Covid-19  lab result classifier for possible ICU admissions.  We also touched on an IntegratedML demo implementation of the ICU classifier.

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.

I have followed the Article: Continuous Delivery of your InterSystems solution using GitLab, On our own Linux environment it works well but when I try to run it on a clients windows server; and the following command is run by the runner

irissession IRISHEALTH -U TEST "##class(isc.git.GitLab).load()" 

we get the following "error"

<NOTOPEN>>

I do not know why this happens, it does look like it has something to do with user rights but I am totally lost at this point as we have done everything I can think off relating to grant correct access etc.

I'm creating a new namespace by the installation manifest XML and in the "database" tag configuration I don't see attribute to configure if I what jounal globals or not to this database.

In the database wizard of the "portal administration", have this option.

Regards,

Lucas Boeing Scarduelli

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
• Why containers?
• Containers infrastructure
• CD using containers
• CD using ICM

In this article, we'll build Continuous Delivery with InterSystems Cloud Manager. ICM is a cloud provisioning and deployment solution for applications based on InterSystems IRIS. It allows you to define the desired deployment configuration and ICM would provision it automatically. For more information take a look at First Look: ICM.

Hi All

I have a question on working with dev and prod environments.

After project is ready and signed, I usually migrate outcome to production using the export tool from the studio.

For changes/adding to existing projects, I exclude the production class (as it has some different values differing the dev from the live) and I add the differences manually afterwards.

My questions on migrating are:

Does anyone has (to share) his/her best practice steps on "migrating dev to prod"?

Does the export action (in management portal) is better to use?

Thanks

Gadi