Ignition 8 Deployment Best Practices

In Ignition 8, we laid the foundation for using source control tools by storing projects in the file system. We get a lot of questions about how to effectively use Git for source control. In this session, we will explore the best practices of using an external source control system and setup a complete example.

Video Transcript:

Travis: Hello everybody, and welcome to the second installment of the Ignition Community Live. So, my name is Travis Cox, I'm the Co-Director of Sales Engineering, along here with Kevin.

Kevin: Yeah, how's it going, everyone?

Travis: This week we're gonna be talking about Ignition 8 Deployment Best Practices. Real quick, the idea of the Community Live here, and certainly we're in challenging times, like many of you, we are working remotely, away from the office. We've had to cancel a lot of our in-person meetings and, of course, live events. And we feel it's really important that we stay connected to all of you, and that we wanna help you stay connected with all the other members of the community because, really, the community is absolutely key to our collective success. So we feel these Community Lives are a way where we can have these open discussions between everybody. In addition to our monthly webinars, this special weekly series of live chats that we've got will include people from Inductive Automation, and sometimes we'll have guests from the Ignition community as well. And we think this is really a great opportunity to talk about releases and projects, ideas and questions, what people ... Innovative ways people are using Ignition, whatever it might be, in a format that's a little more informal and freewheeling than our usual webinar, so that we can really have those open discussions.

So we hope that you participate in these chats, and let us know what kinda subjects you wanna hear about in the future. So feel free to be a live part of this, so that you get the most out of these live chats. But we get a lot of questions on how to set up proper development testing and environments, and also how to utilize source control. Not only do we wanna help customers with it, but we wanted to create a document that follows it, so that you can go refer to it later and really be a part of the best practices for how we can do that.

So Kevin and I, we built this new white paper that is aimed to help you better understand how to deal with deploying Ignition applications, and provide some best practices for setting up your development testing workflow. Having a really solid deployment workflow allows for better change management, it minimizes mistakes, and it leads to a more productive team. And so we're happy to be able to bring this to the table today. And we're gonna go through this white paper here in presentation or slide form. You see the link that's right here, on our resources section of the website, you can go and check this out. You can also go to the resources page and search for it, you'll find the Ignition 8 Deployment Best Practices, there is the information here about that, which we're gonna go through today, and then there's also of course a PDF that you can download. Before I jump into the next slide, we've got a question, "Do we have access to previous webinars?" So if we're talking about full webinars, we have pretty much everything listed out on our website, from all the different types of content. So some of you might or might not be familiar with this already.

So basically, I did wanna take a step back and take a couple of minutes for any folks who aren't familiar with this model right here. 10 years ago, when we released Ignition, and we were taking a look at the staging versus production projects, and we've had that as a trope inside Ignition for quite a while. You could be forgiven for thinking that that was the way that everybody did it, where you had a staging project, and then you hit "save," and then it pushed it out, because larger organizations were starting to move to this type of model already. And what you see right here, development, testing, QA, production, this is more of what they, in modern days, call kind of a DevOps model, that comes from the IT world, but works extremely well for applications like Ignition. And so we've seen a huge amount of increase and interest in having a full-development, full-testing, and full-production system for our models. And so basically what this looks like, whenever you're building an Ignition application, if you're doing something that you are wanting to be careful about how you're making changes, rather than just having a single production system that you're making changes on actively, even if it has a couple of projects, that's a staging project and a production project, and you're pushing things out between them, it's still a single system.

That system goes down if you're doing development on that system, and things aren't working how you want them to, or somebody new is coming in, and they have access to all the projects on the production system, and they make some changes by accident on the wrong project. All of that could be things that hurt your production environment. And so because of that, often folks will go to a separate development system from production. And then often there are testers, and so you want the users to be able to test things, you wanna be able to make some rapid changes, maybe on the development system here, push those out to a testing system where folks can QA it. They can make sure that things are working right with any new changes, with any new developments, and then push it out to a production system where that production system becomes the only system that is used on the plant floor or in the facility or on the cloud or wherever you have Ignition running. And the things that are ... The changes that are ever requested go through this development process to testing, QA, and then out to production.

So any changes, any releases going to production are individual releases. So they're done at a specific time, they're done in a way that everyone is informed, and they're letting know that this new change is coming. Some folks use version numbers, and they say the new Ignition application Version 1.1, we just added in our development Ignition server, we pushed out to our testing Ignition server, everything looks good from testing, now we're pushing it into production. There's different levels of how deep you can go with this and how strict you have to be, but in general, our recommendation these days, for anyone who's doing anything serious with Ignition, is to have this type of model right here, where you can do development, to testing, to production. And you're not risking changing anything on your production system as you are in the middle of doing things that could be really innovative on the development side, and pushing the envelope, and really advanced and cutting-edge. And then you wanna push it to a testing environment, where you can make sure that everything's going to work right and things are going to continue to be solid and to be stable on the production side, when you do push it out from testing to production.

Kevin: Yeah, and so in order to really do this effectively, I think it's really important to understand, that when you're developing Ignition, understanding where things are being stored, and how things are being configured, and how it's all broken up. And so I think it's first worth pointing that out, going through Ignition's configuration with more detail, and talking about the role of the four main areas of the config, which happens to be the Gateway configuration, Tags themselves, Images and Projects. And we're gonna go through each one of these. So we start though with the Gateway configuration. This is the area that you see and manage when you go into the Gateway configuration webpage.

So all of the connections, you know, the databases or devices, all the profiles you set up for like authentication profiles or alarm notification profiles. All of these settings that are in that Gateway webpage are what I'm referring to here. And these are all stored inside of Ignition's internal SQL live database, that is on the server itself. There is no import-export for any of these profiles or settings. And that's a really important thing to understand here. For that, there's also no EAM support, meaning that from a controller I can't go and add a connection to an agent Gateway through EAM. We don't have either of those pieces right now. So the way we back this stuff up is through our Gateway backup. And we don't wanna backup ... You never, ever, ever wanna take a backup, a full Gateway backup from a development or testing system and bring it to production. Because that's gonna bring everything, it's an all-or-nothing restore that potentially has configuration that would be different on the development side.

We're gonna get into more detail on that here in a moment. So when we're looking at going from dev to test to production, and deploying it, this area of configuration is very much manual from each environment. And it's really about defining a process that you can follow to make sure that you're doing this in the most effective way. But I'd say, this is probably the biggest area right now that you have to really pay attention to, with this kind of workflow. And hopefully in the future, we'll put more of our configuration into the file system, so that way this'll be a lot easier, like we do with Projects, which we'll get to in a moment. But as of right now, this is sort of how the configuration works for the Gateway. Often, and we haven't listed it on the slide, but often each one of the environments will have different configurations for all of this. So even if there was something that you could synchronize all your Gateway settings, and there's a good chance you wouldn't want to synchronize a good portion of them. So, for example, your database connection might look different on test than it does for on dev, as it does on production. Because you're going to be using different databases behind those, because they're different systems.

Your device connections might look different. Your system names definitely will look different. Your Gateway Network connection information, and the accepting clients, and which one is the controller, and all of that configuration will be different between these systems as well. So it is important to be careful to set these up separately. And generally, after you've set them up once, you're not making very many changes to the configuration when you are pushing things out. Most of your changes are going to these next few areas and especially the Project area.

Travis: Yeah, absolutely. And we'll talk, we'll get a little more of those in a moment. There is a slide related to that, just so we can cover it. So the second area is Tags. And tags are a very important part of most projects. They are not stored in solid projects, but they're important to projects. And they are points of data that you have. They could be static or dynamic that come from OPC, come from expressions, SQL databases, they could be memory values, whatever that might be. And we can use these tags on screens, and transaction groups and every other place within Ignition.

And so we developed these things in the Designer. They are also stored inside of Ignition's internal SQL live database on the server. There is, though, an import-export, and you could do that through XML, now the new format is JSON. We also have EAM support for this, we're gonna show this today. So you can actually move tags through EAM. And then from a dev test to production, no flow, you have two choices. You can either use EAM to push changes from one system to another, or we can export and import using that JSON file. Again, manually do that, but at least we can, you know, make it easier by exporting it, and then bringing it over to the other system. So anything to add there, Kevin?

Kevin: It is worth mentioning, you can mix and match things inside this dev-test-prod environment, so that you're not necessarily just using straight OPC tags for everything. So we'll go into more detail in a few moments, but you could have MQTT as part of your data infrastructure, where you're sharing tags between these systems. You could use the Gateway network, where you're sharing tags between these systems in different ways. You could have a separate set up where you have separate devices in a way, and just have it so that some of your tags are not actually living on each server. And a lot of folks end up doing that as they're setting up these environments. So, this is talking about taking tags that do live on those servers. So anything that you have as a memory tag, anything that's an expression tag, anything that's inside that local tag provider, and this would be the way to send those out. A lot of the other types, just are automatic.

Travis: Yeah, anyway, and we're continuing to allude to understanding the differences between each of these environments. So no matter what, with any configuration is important. Next area is Images. These are also not stored inside a project. They are separate to the Gateway, managed through the management tool inside of the Designer. And the images that we can work with PNGs, JPEGs, GIFs, SCGs, all of that. They're also stored inside of our internal SQL live database on the server, where you can import-export them through the image management tool in the Designer, there's no EAM support for this. And so if we're deploying, we're gonna be using the import-export. Meaning that if I upload an image on development, and I need that image to be on production, I gotta export that image, and to bring it over to the production environment, import that image in there. And often, this gets overlooked because people assume they're inside of a project export, and they're not, along with tags too. And so we have to... Each of these environments, so these areas have to be looked at bringing over to the other testing or production environments. And you have to, kind of again, develop your workflow for that.

Kevin: One quick thing to add to that, if you've never done anything with specific images, if all you've done inside Ignition is use Symbol Factory, that doesn't qualify for what we're talking about here. There's a section that ... I've talked to a growing number of folks who say, "What is image management?" There's a separate section inside Ignition that allows you to upload images under the Tools Image Management up there. If you've never used it before, you'll never need to synchronize images. If you're just using things from Symbol Factory, those end up inside the projects, which we're gonna talk about now.

Travis: Yeah, good point. So the main area of configuration is Projects, that is the main unit that you're developing Ignition, and we spend a lot of our time in the Designer working on Projects. And these are all of the elements that do the real work. From building interactive elements like screens, and windows, and templates. Of course, but there's scripting functions, there's pipelines, there's transaction groups, there's sequential function charts, there's reports, and name queries. All these things you see in the project browser within the Designer, that is stored in the Project. And now with Ignition 8, we are storing all of that into the file system. So if you go on your server, look at the data directory you'll see a folder for Projects, and all the projects will be in there. In fact, when you do an export of that project, you actually will get a ZIP, which we're now basically just zipping up that directory on the server for the individual project. So it makes it really, really easy to work with, especially when we're talking one of... With today, looking at source control, how we can easily integrate with that.

So with that we can import-export through a ZIP file. You can also individually export things if you need to. We also have EAM support for this. You can move projects through EAM. And when we go from... We deploy from dev to test to production, we have three options. We have EAM, and we have import-exports, and we can also use source control. For the sake of this, we recommend using source control, because it gives you that change management that everybody is looking for as we go forward. So you can define what, how you wanna move, and which system you'd want to use when moving our resources from dev to test to production. So we're gonna spend, again, a good amount of time on the Projects here. But this is the area that's probably the most important when looking at... This is probably the most active development that's gonna happen on the server and the most that will change.

Kevin: And this is actually one of the things that we spent a lot of work on, that our development team, our amazing development team spent a lot of work for Ignition 8 to make a conversion over to the file system, so that it actually could work like this. So they spent many, many weeks converting our previous format for all of the different files that we have, from where they were on the internal database to format that. It's very easy to commit to version control. And so this is one of the big new features that Ignition 8 brought about. This doesn't apply to Ignition 7.9, but it does apply to Ignition 8. In 7.9, this has EAM support, import-export, but it doesn't have the storage on the file system. I think that's worth noting. On 8 it does, on 8.1 it does, or it will, you know, 8.2, 8.3. Going forward, that file system storage is where all of these project files are going to.

Travis: Absolutely. So Kevin, let's look at what this would look like, from an Ignition workflow, taking that dev-test-prod, and when we need to create architecture diagrams, we often come up with something like this. So why don't you go ahead and explain.

Kevin: If I'm creating my first Project, and I've never created a Project before, on the left-hand side you can see Development. And that's that column there. So from that workflow, the Ignition server there, and then down on the bottom are its database, and then any devices, or as we'll talk about in a minute, device simulators, or device tags that are available there. And then going through to that Ignition Development Server. So, basically, if I'm creating something brand new, I have this great idea for a project that I want to create, I go into the Development Server, create a new Project, and it lives there. And then I want to share it with the world, I wanna let folks take a look, give me any feedback on how good it is, or if I need to go back to the drawing board, or if there are improvements that they're requesting. And so I'll take that Project and push it out to test with some of the mechanisms that we were just talking about there. Whether that's EAM, or source control, or copying images, doing an export-import. And that'll go from development to test. We have these four different areas to make sure that we move out to test.

On test, as soon as I spin up that server I'll want to configure the Ignition Gateway, so that it is similar to the Development Gateway, but it's pointing at its own things. So it's pointing at its own database, its own PLCs, if it has its own set of PLCs, or simulators, or connected up to the same tag infrastructure. And then from test, users will log in, they'll take a look at the system, they'll give me any feedback. I might iterate on it on the development server, make any changes that I need to to accommodate the new future requests or any problems that they found, and then I'll have a shining, perfect application, I'll push that out to test for one final test from the users. The users say that it looks good, and then I'll push that out to production. So I'm going to take what's on testing and do the exact same thing. So push it out over EAM, or over source control, or do the image export-import, or the Gateway configuration. Do the configuration on the production system that's going to match the other systems, but also it's going to have some changes and differences, so that it's pointed at its own database, it's pointed at its own PLCs or its own devices or its own tags, where appropriate.

And then that production release will become the release that everyone who's running an Ignition client or Perspective session, everyone who's opened up and taking a look at Perspective or Vision is going to be running on that production system. Then if I make any changes, those changes happen on development, I push those out to testing, I get feedback on those, maybe iterate in development, and then when I'm happy, push that as a new release from testing to production. When that's pushed from testing to production, always want to coordinate with folks and make sure that people who are using the production system know that it's happening, know when it's happening, know what features to expect, and it can be an exciting thing that a new release is coming down the pipe. It could be something that a lot of users in production are getting some of the features that they've been requesting. So, that's the basic flow of how this works for most companies who are doing it like this.

I should note that there can be some deviations to this. Some folks actually combine development and testing into their own server, and they just have one server for that, and then production is a separate server. But our recommendation is always to have it split up like this, so that you have the most separation. And so that development can continue even when you're testing something that has been pushed out that you might want feedback on, but you're monitoring and redeveloping other systems, other features, other applications at the same time on the development server. Travis, anything to add to that?

Travis: Well, I think that last point is really important there, and to have separation, because you look at the development environment, there's two camps in how you can look at the development environment. You can look at it where you have a shared development environment, this is one that most of our customers look at using, where you have, essentially, one development branch, one development server where you're making all the changes. Everybody's kinda going into there. And you can't control what other people are potentially doing, so when you're testing it, you might have... You might be testing pieces that are incomplete or that other people are currently working on, and that could lead to some issues when you move to a production system. So, having them separated when you're done with that piece of development, merging just what's needed to testing, then you can properly test that piece to know that you tested what you needed, to then, of course, moving that to production. So that's one camp.

The other camp, of course, is where everybody has their individual development environment, meaning that they have Ignition on their laptop, they have the project loaded there, and they're making their own changes. If you will, from a source control system, developers would have their own branch on that, and there would still be a main development branch that they would merge their changes into, that then would get brought into, say testing or into the next piece of the workflow. So I think it's really important when looking at development environments to kinda figure out how you want to approach it, and having that being separate from testing is a good recommendation there. But with that, Kevin, I know there's a bunch of questions that people have from a development environment, and especially if they have individualized and dev environments. And of them is, "Do I need the development testing environments to be licensed for Ignition?" Why don't you answer that?

Kevin: Sure, yeah. So the answer is right there on the screen, very simply. You can use that two-hour trial period. So if you want to, you can install Ignition, configure it, have it running in that two-hour trial period, and you don't need to pay for those licenses there. We do have options if you do want to pay for licenses that you can talk to your sales folks about if you're interested, but yeah, we recommend using that two-hour trial period, if that's going to work for you. If you're not doing development all the time and you're just doing this on a simple system, it's often just easier to use the two-hour trial, you don't need separate licenses, and you're good to go.

Travis: And keep in mind, the development environment does not time out when that trial period is over. You can keep developing and all that. It's just the runtime and, of course, the logging and all those pieces that time out, that you then just gotta reset. So from a development standpoint, you can keep developing even if it's past that and keep working on it without it being licensed. So that, it's a good thing. So, "What are the differences in Ignition's configuration for each environment?" Now, Kevin, I know you've talked a little about this before, but I think it's important to really illustrate those differences because there has to be differences between each of the environments. They cannot be exactly the same, right?

Kevin: Yeah, yeah, absolutely. The different environments, we talked about a couple of these, but yeah, devices or PLC connections are definitely going to be different between the different environments, unless you want your test environment, your development environment to use the live data. Sometimes those connections are even set up to be read-only connections, which is more likely if you have OPC UA connections between different systems, or you're using a gateway network to share tags. OPC UA connections are often different. Database connections are always different, because you do want separate databases for each one of these systems. You have the same database, then you're not able to really fully test things on test because you don't wanna change the active database. So if you're changing recipes, if you made updates to a recipe editor, for example, or if you've made updates to form entries, you wanna be able to go through and click those and test those and type information and try to break it, and then fix it, if it's broken, right? But if you're connected to a live database, you're not going to be able to do that. So, running through and having individual databases for each environment is really important.

Authentication profiles are sometimes the same and sometimes different. Alarm notification profiles are often different, because you often don't want alarms from QA or from dev going out to an actual live set of users. That's going to confuse the users, especially if you are not in tight communication, but even if you are, generally, you wanna test to a different group than you're doing to production. Redundancy settings, often the production environment is a redundant environment, whereas, dev and test might not be. Or sometimes, dev is not redundant and test is redundant just so that you can match the exact environment from test to production.

Travis: And there's more, right? You really have to look at the config and think about the differences between the environments and, "Do I want it to be the same, or do I want it to be different?" And that drives a lot of how that works. And that also will make sure, when you develop your process, to know what I cannot move from one environment to the other because if I do that, it's gonna potentially cause things to break or go against the wrong system.

Kevin: Yeah, absolutely. We've got a couple of questions here, and I think it might be good to break, just to answer those. One of them says, "If you're using VMs, it is the best practice to have a dev VM, test VM, a prod VM or can that be done on one VM or a physical, or... I think the question here is, or should we use physical servers?"

Travis: Yeah, sure. So, I think it's whatever makes most sense for you. We understand a lot of people today are going in VM environments and would prefer to have separate — would have VMs. And of course, we would like you to have separate VMs for each of these environments, dev, test and production. But it could also, of course, be a physical machine if you have a facility for that. We see a lot more dev-test with VMs, because it's easier and you can spin up potentially them both on the same VM infrastructure than having to have physicals. Maybe your production system might be physical, because it is critical to your operations, versus relying on virtual machines. So, I guess it comes down to what your requirements are but, again, mostly, we see VMs I think for those dev and test environments. Anything you have to add there, Kevin?

Kevin: Yeah, just a quick note on VMs in general. I think that answers the question great. On VMs, and I try to emphasize this whenever talking about VMs, please, please, please make sure that whoever is setting up the VMs gives them dedicated resources for anything that's going to upload. For the dev VM, maybe it doesn't matter so much. But for the test VM and for the production VM, especially the production VM, having those dedicated resources is something that is pretty key to Ignition running well and scaling well. I often look at it this way. You don't want to run a $10,000, $20,000, $30,000 piece of software on a $1000 worth hardware. And if that's all the VM that's been allocated on the virtual machine, then you're really doing a disservice to Ignition. It does a lot of virtual processing and, at the very least, those processing cores should be dedicated to Ignition, whichever ones are allocated to it.

So, the next question here is, "Is Symbol Factory still restricted in trial mode?" And I'm happy to say that it is not. So, in trial mode now, when you're running the, what we called, in the demo mode or the trial mode, that two-hour trial mode, you can now, with the latest version of Ignition, use anything from Symbol Factory.

Travis: Hallelujah! So, another question we gotta look at, when we look at the different environments is, "How do we work with tags and simulate real device data on development and testing?" 'Cause sometimes we can connect to the same PLC, and you may want that; sometimes, of course, you can't, they have to be completely different. And so, you really gotta take a hard look at the tags themselves. And when we do look at this, we also wanna build tags in, where if I build a tag on dev or test, that when I move it from that to production, that I'm not having to change that configuration once we move it from dev to production. Because then, a lot more manual work, a lot more potential for things to have problems. So, Kevin, this is a big question I know that we get tons and tons of. I'm asking you to answer all of these ones here, but this is one that you've also alluded to as well. Why don't you go ahead and answer this question?

Kevin: Yeah, absolutely. So, the options that you have here for simulation. Let's say that you're not connected up to the real system in development and testing, you're not connected up to... When I say the real system, I mean the real network of PLCs, the real running whatever system that you're developing against there and you want to have these simulators that are running things. How do I simulate that? OPC UA or MQTT will allow you to connect up to the real data possibly in a read-only manner. So, OPC UA, by default, is going to be read-write, but there are some ways that you could expose tag providers and have those tags set up to be read-only. It takes a few more steps there if you're doing that OPC UA through Ignition to make that read-only, but it is possible there. MQTT, it's very, very easy to make read-only. So, there are these access control lists that you can set up and set folks to be just read-only over the access that they have there. So, if you have MQTT, that can be a great way to share tags where dev and test are read-only to those tags, but they are the live values that are coming over the wire, essentially, to test into dev.

Gateway network is another good way to do that, where you can connect up over Ignition's own built-in Gateway Network setup for remote tag providers and then each one of those tag providers can be set up in a way that is read-only with the service security tab there. And in fact, when you first set those up by default, they are read-only.

Travis: We just had a comment come in here and I'll read the comment because I thought it was really good. Additional PLCs is part of what the comment was about. So, often, folks will actually set up separate sets of PLCs for test and for dev, especially if you're working on a completely new system that's going to be installed. Having a copy of that PLC program running on other PLCs is often a good thing. Or, if I jump all the way to the bottom item here, you can run that PLC program on PLC simulator software and often, it is very, very close to how that PLC's going to run it; close enough that that might be an acceptable option as well. If you're going through the PLC simulator software, if you're using the Siemens stuff, if you're using the Rockwell stuff, we have customers who are connected up to that. In fact, on the Siemens items, I just saw a video on YouTube the other day that somebody had gone through and showed exactly how to connect those things up. On the Rockwell stuff, if you're using the Emulate or the SoftLogix, connecting that up to a factory-type gateway over OPC is the way to do that, and that generally works great.

The other options for device simulation. So, if you don't have a program written already or you just wanted to simulate some basic tags, we have a programmable device simulator, which is a fun device that is new. We previously had this but it was locked in and really specific in how you could set it up, and now it's pretty flexible. It's not going to take inputs that are coming in and react to those inputs from Ignition, but it is going to let you generate sine waves and PID. Not full PID loop control, but PID for individual tags where it's settling at a certain point, if you're taking a look at the mathematical PID, right. And there's actually a bunch of different functions, and so you can create different times for each of these functions as well. So something loops from high to low to high to medium to low, and you can get pretty advanced with that. And then if you want to go really advanced, inside Ignition you can use sequential function charts and for these you can simulate flows and off-auto OCAs, have it respond to different things, and basically pair these sequential function charts up with memory tags that are inside Ignition and then that's going to allow you to interact with things.

In fact, if you were at the Ignition Community Conference, you probably have seen that at some point. We had some SOCs that were driving some of the simulators that we've used on stage at different points. I've used them kind of all over the place. They weren't used for the Build-A-Thon because they were actually using the Opto 22 PLCs there. But the SOCs have been used for a whole variety of things that you might want to look like real responses without running additional software.

Kevin: Cool. A comment that we have here was a comment that came from Lynn that said, "It's important to also have test PLCs, so where we're talking additional PLCs, that's where that fits in. We have had problems with two servers using the same PLC and it creates a risk condition with unpredictable results." Absolutely. For example, a tag change event that flips an open C tag. Most of the time the production server is faster but sometimes the test server or the dev server win. So if you have to read-write access and you are doing things that write to production PLCs, that is sometimes the recipe for disaster, so yes, having additional tags or additional PLCs is a pretty important piece in this infrastructure.

Travis: Yeah and that's really important. You have to when you look at testing, there are certain things that require timing and you need to have that kind of isolated, so that you can fully evaluate that with the right, hopefully, real-world scenario that's out there. It's a really good point. The last question here is, "What about custom SQL tables that I want synchronized across each environment?" So as we talked about having a dedicated database to each environment is important, and when you do that all of our systems like our historian and our alarming and all that, we create the tables, we manage all that, no big deal. But when you have custom tables, maybe that you're interfacing with Ignition, transaction groups, or other places, those tables need to exist in all the environments, especially if you make changes to the structure or if you add rows of data that needs to be there on the testing or production sides, you gotta think about being able to bring, to deploy that and how that works. So there are tools that databases provide for some of that, as well as you may just do it manually. So I think it's important for you to come up with a plan, how you wanna do that and make sure that they're in a checklist.

That's one of the items that you're looking for. Did I do this? If not, no big deal but if I did, what do we, how do we respond to that? I mean we talked about the testing environment, that's where the quality assurance comes into play. The production environment, obviously that's where everything is running and where people are accessing, but I wanna say when deploying to production, make sure you do it at scheduled times, and that the whole team is aware of those deployments, and you version that, if you will. You know what's happening. That is, I think something that often you deploy something real quick and somebody didn't know about it, and you got all these weird things that potentially could happen. So, part of the change management control is also controlling people and teams, and it is important to be in communication with that.

We mentioned EAM a couple of times, Enterprise Administration Module. It is important in having that, having a — oftentimes the development environment will be the controller and then you have the agents that it connects to and you can use the EAM for checking health and diagnostics as well as deploying certain things if you want to use that. We're gonna be showing a source control system here today and these are external to Ignition that a lot developers use, of course our development teams use and these can be things like, you might use GitHub or on-premise you can use GitLab, something like that or other Git systems or SVN or whatever source control system you'd like to use, interface with. That's where we're gonna do all the version control and track the changes of all of our projects and there I want to talk about how to do that.

Kevin: Yeah, yeah, so we had a great question that just came in which I think we're gonna show here but I wanted to answer it quickly. “If I use Git to push a project to production, will Vision clients automatically update like when you save the project in the Designer?” The answer is yes, absolutely. So we designed the whole project-save file system, save of those resources so that it does automatically update Vision clients, Perspective clients, anything else that's using that file system it counts as a project update that was just sent through. And in Vision, you can have it set up to either be the automatic update where it pushes that out or where it gives you the bar across the top and either configuration there, you're going to get what you expect, the same as someone hitting Save.

Travis: Absolutely, and we'll show that here. So source control, you can use a lot of benefits to it, of course, and Ignition and source control together, I think is a good combination and looking at those four areas, projects, tags, images and Gateway configuration, coming with a plan how you're gonna commit resources to source control so that you can track those changes as well as of course how you are you're going to deploy and move from one environment to the other. Again, make your plan. Define your workflow, define your process, create a checklist for deploying to make sure it's accurate. I think these are things that are important and I also think that give your developers cheat sheets and they know exactly what to do with this process. So here it brings us to our example. What I have set up here is we have an environment where I've got Ignition on my laptop, that's gonna be the production system. So I've named it Ignition-Production.

And then I've got in a virtual environment, I've got two VM's, I've got one that is, it has GitLab installed. So, GitLab is a kind of open source GitHub implementation I can have on-premise. And I'm gonna show, creating a project there. And I've got the development environment here, that's another VM, with Ignition already in place. So I've got the development environment and my production environment's up and running. We already have them up, we have connections in place, we've got a Gateway Network established so that there's a communication between the two, and we have EAM already configured to save some time on all of this, but I don't have any projects yet. So we're gonna show going through and making this happen. But on my development system, I have a connection to a database that is local, so it's a MySQL database on the same machine here, it is local. And on my production environments I've got a database connection, it's gonna go over here, that is going to a Postgres (SQL), that is local to the production environment.

Again, they are different but the name of the connection is exactly the same. That's incredibly important here again, so that our configuration from one environment to another is the same. But so there are different databases but the name is the same across that. I've also got a device connected here, and we're actually using... On the development environment, we're using the programming device simulator for MicroLogix, for MLX. And we've configured this to basically use this new simulator, where I've got a couple of realistic values, N70, N71.

They're adopted, I'm simulating, whereas, of course, in my production system, I'm gonna be connected to the real MicroLogix PLC, as we can see here. And name again, the same, MLX. And when I create tags, I want them to be the same across the environments as well. So, I wanna show a couple of things that were set up. Again, there's no projects here, so what we're gonna do is actually go in and create a project. So let's go launch a Designer on this system. I'll create a new project from scratch here, and I'm just gonna go ahead and log in.

Kevin: While that's loading up, we've got an additional question here, and a comment, I guess, "Great stuff." Thank you. "Already downloaded the PDF and posted it to the group, any plans to add a source-control set of videos on Inductive University?" A lot of what we're doing with source control that you're seeing today is all enabled from what we've done with Ignition 8, where we have things on the file system, and where we're taking advantage of the ability to do things with that. Sometime in Ignition 8.1 or 8.2 or sometime in the future, we don't have an exact date or exact release against it, but we are looking at integrating source control tools right into the file: save, merge, that type of thing. I think at that point, when we add even another layer of integration here, we will be looking at doing a set of videos on source control, on using those new tools in the Inductive University, absolutely. In the meantime, there's a lot of good videos and material for GitLab, GitHub, for these, which are probably the two most popular packages that are out there for version control in the world. And so developers everywhere are using these packages. Yeah, lots and lots of good training materials, if you've never used Git before.

Travis: Yeah, so I got the project up and running now called "Demo," so if I look at my — on the dev environment. I got the projects folder, I got a folder for Demo. Everything's set up, ready to go on that. I do have two tags set up here, and these are going to that MicroLogix device simulator, and you'll notice that the path, the OPC Item path would be exactly identical if I was connected to a real PLC. So right before that, it's gonna work on the production system, but against the real PLC, at that point. So again, we'll come back around to that. I'm gonna go to GitLab, and I don't have a project yet. So I'm gonna go into GitLab here, it's a blank installation of this. We're gonna create a brand new project for this, we're gonna call it Ignition, and I'll make it here internal and I'll go ahead and create that project. So now I've got a project that I can store my development to. And it's ready to go. So using Git commands, you can get that all started. So let's go back to your development, and what we're gonna do is follow these commands here, and it's in the guide as well. For a second, I'm just gonna do some copy and pasting here.

So I'm gonna knit this directory and this, I'm in the project's directory. I'm going to then add that remote origin. We're gonna add everything in there here. So let's do it, I Git add everything that we've got in there, and then we're going to commit that as the initial commit, and then we're going to push it to the source control system, so let's go ahead and do that. So now that's all pushed over there. And what I'm gonna do now is set my branch as the master. But right now, I don't want it to be a master forever. If I go back to here, you actually wanna have multiple branches of your development, and so let me go ahead and refresh this page. You're gonna see that I've got everything committed, I'm gonna go and set up another branch in my source control for development. And it's gonna copy over stuff from the master, so it's gonna be good to go on that.

And so now I've got the development side, what we gotta do is go back and make my development environments, we're going to make that look at the right branch. So we're gonna fetch all the branches, we're going to then go ahead and check out the developments, and then I'm going to set this as the branch that I want, I'm gonna set that as the development now, so if I look at the status, you can see I'm now on development. So if I go ahead and make a change, let's say we go into this... That was the wrong screen there, but let me go ahead and... And if I were to make changes and save this, then we can push that change, of course, to our production system. So let me go ahead and... Let me close this one. I'm gonna open up a different window here. So in any case, I do have everything going, I can commit more changes to that, no problem. And now that I, when I have that, I wanna be able to pull that project on my production system. So over here, I don't have that project yet.

So it says on my laptop, the host, on that project. What I'm gonna do is go into that directory. And with this, we actually have to, we're gonna pull that entire directory. So if I go into data, you'll see a Projects folder. And so what we're gonna do is, we're going to clone that from that server, but we gotta delete, gotta delete that project folder real quick, and then we can bring that in. We got to be kind of quick with this because... Ignition wants to create that directory again. And there we go. So now I've got that directory created, and in there is my demo project, and it's ready to go, so I'll come back here and refresh this particular page. I now have got the demo project here that I can work with. And from there, when we deploy it, we can just pull our changes on our production system using Git, pull to make all that happen on there. Kevin, you were gonna mention something there?

Kevin: Sure, yeah, I was gonna say, do keep in mind that this is the initial setup. So this is, this is from scratch, this is fresh, what Travis just did here. And now at this point it is set up, so I'm assuming what he's going to show next is making a change here, and then being able to push that change out.

Travis: Absolutely, that's what we're going to do here. So we're going to, I'm gonna take this tank, I'm gonna bind it here to that tag, that temperature tag, let's say, of course it's, now there we go. Now I'm going to make my save and that makes a change. And once we do that, we can, we do need to push that change. And so what we've done, and this is what the guide says is, I actually have, so going back here, I have this actual shell script, which is basically going to add and save and then push that to the development branch. But I would like that to actually happen automatically. So what we can do is go to our Gateway Events, and there's a new one for Update, and we can put this script in here basically it's going to, and it's also going to take an export of the tags and store that there as well, call that 'sh' to basically commit that to the source control. So I'm going to go ahead and do one more thing. I'll just move this over here, and I'll save this. And so now that save is going to call that script and that script is going to go and update from that Designer save. So if you look, if I look here, it's a five-second delay on that, so let me go refresh now.

And we should see that that commit actually be automatically pushed. So basically it can call those commands right from the save in the Designer to basically get that over there. But at the moment you should see, when that does refresh, we should see that new change being reflected in here, that we can then pull from our production system and have that, you know, that change come through. And let me get this ready to go. So I've got this project, while waiting for that to actually go through. I'm going to launch this project that doesn't have, my production system doesn't have that tank that is there on that. So let's go back here. There we go, it's starting to load now. This is a note that harkens back to what I was just mentioning about VMs and production VMs, make sure you have dedicated processors right there.

So you can see now that I've got that Designer save that is over there. We can then create a merge request, and this is within the environment, we can say, "Okay, I'm ready to merge, I want to take those changes and bring it over to production." Now I don't want to delete that branch though. So I'm gonna submit that merge request, so that we can have that merge to our master branch from the development branch. And this is again, source control tools here, and so at its finest, and again, there's a lot of, you know, videos and things that Kevin was mentioning about how to use these. I'm gonna go ahead and merge this in, and now those changes are going to be there on the production side. So now what we've gotta do is come over here and do a Git pull from the master branch. Oops. Go back into projects directory, Git pull, and I got that change. And now, once Ignition sees that change in the, from the file, from what was there, it's going to have that updated here and reflected in my Perspective Projects, although I don't know why it's not.

Kevin: So in the meantime, I will answer another question here. So we had one more question come in that said, "When I tried this, I found every file, the last edit timestamp was considered a change, resulted in multiple merge conflicts. Do you know a way around this?" So if you're using a single dev system, you shouldn't end up with that issue. Basically, if you're using a single dev system that everyone is developing on, and you're launching Designers from there, then you will get any changes that you're made, you're making to that in an individual way that, where that development environment is going to simply have one change that that's being pushed out to git. If you're using multiple different Ignition Designers, maybe follow up with us after here, if you had separate Ignition installations, in addition to the Designers, that you're trying to push out to the same repo. We've got folks that are doing that today, and so we, I'm sure we can find a solution there. But if you are using that single dev server, then you shouldn't run into that at all.

Travis: So I pulled the change here, you can see the tank is in, but oh guess what? But it's not linked to that tag. And so, this I did on purpose because this is to point out the configuration that we talked about. There are those four areas, all I did was pull the projects, I did not pull any tags that I developed on the production system. But keep in mind that my production system is talking to that PLC at this point. So this is where you have the options, import, export, all these kinds of things to bring it over. I'm going to use, in this case, I'm going to use EAM real quick, and this will finish out our demo. Again there's no tags, we're going to go back over to our development environment, and I'm going to right click on these two tags, because I have it, this set up as controller and my production system as the agent, I can say "Send Tags to Agents", and now with that, our remote agent...

Although that is not there, so the idea is, I don't know why I think my EAM or my Gateway Network might not be working at this point, but you can actually have it select that agent, and you can have it sent over there. And so what I'm gonna do is just gonna do an import here manually, and so I'll come in here and import. Let's come into our "news.tags" there and those are the tags from the developer side you see is working perfectly on the production side. Going back to my client now it's up and running here. So you got to really think about all of those areas of configuration with that. So hopefully we got a sense of how all that can work, the guide talks a lot more about that. So you can actually have these environments be the way you want for that. We do encourage everybody to try Ignition, especially Ignition 8, for yourselves. Try all this stuff on your own. University is a great tool for learning how to do things in the product. Not all the stuff is in there, but we do have that white paper that's there. If you have any questions or comments you wanna call us to set up demonstrations or calls. Kevin and myself as well as our sales team are really happy to do that.

Kevin: I did wanna mention one other thing with this, with the Ignition Community Live. We have a Perspective one next week. What I want to do with that is show how you go from a single system to something where people who are working from home have access to the system. So setting up a read-only Ignition Gateway with that all it has is the Perspective Module. Connecting that out to your existing 7.9 infrastructure, your existing 8 infrastructure, and then being able to serve things out and just building a simple quick screen for being able to take a look at real-time data and by default that's normally read-only. But you do have the option of going control, if you follow the security hardening guide. And then after that we have something with Sam Russem from Grantek as one of our visiting folks who's gonna be talking to us. We have something from Cirrus Link, we have something from Sepasoft in the coming weeks. And so our schedule is filling out here.

Travis and I plan to continue to be involved as we go along, as well. Depending on who we're talking to but you might some other hosts as we go along too. And we have one last question that just came in actually. "Some parts of the source control were a little fast. Any chance we will get a copy of the presentation?" Good question, I think we might be able to make that available, but more importantly that PDF has all of those steps there. It has it listed out, it has it enumerated, it has, "These are the ways that you do it. Go through step one, step two, step three, step four." I would just go from that PDF as a guide, it should have everything you need inside there. That's all set up for GitLab. If you have GitHub instead, you can reach out to us. We have a simple white paper we put together for GitHub that has the steps for GitHub as well. But we're trying to make this as easy as possible so you don't need to look through a set of slides to try to understand how to do these things, we wanna give it in a format that's gonna be easy to follow along. And that's what that PDF is all about.

Travis: Yeah, thank you everybody for joining us today and we look forward to see you guys next time. Have a great rest of your day and everybody stay safe out there.