We’re looking at testing some additional plugins with a potential to buying. I was wondering how easy it is to duplicate a Service Desk instance for testing but remove the email interfaces to ensure nothing is sent out or received by it, can someone please advise? Thanks.
For cloud based installations, Atlassian recommends to order the smallest user tier for such stage-envrionemtns. Afterwards you have to copy your data using the export/import functionality of JIRA to populate your production data to your staging or testing environment.
Have a look at these pages:
atlassian-cloud-staging-and-testing-environment
import-and-export-data
Related
I have a very simple NetSuite scrip that sets the value of the externalid when the record is saved. I have done testing on the SB account and it is working as expected. Copying the same configuration into the production account and the script is not executing. I've even added some dialog boxes to see if I can see any activity but there is none. The script is deployed, released and has "all roles" as the audience.
Any ideas what I can do to get the script to work?
Thanks.
Is your sandbox a very recent copy of Production? Does it have all the same scripts deployed as there is in production? You may want to look at the scripted record list for User Event Scripts in both environments, make sure they are the same.
You could also post your code here for us to look at it.
I just started working with EPiServer (Sitecore before) and looking for a way how to synchronize content between environments automatically (developer-developer and developer-QA env).
We have our QA environment on an azure virtual machine and need to synchronize content during CI/CD.
EPiServer DXC Service doesn't meet the requirements because we are not working on a web app service.
Any ideas? Is there any already existing way to achieve it?
Automatic synchronization between environments has [more-or-less] gone away within the Episerver platform. The old way of doing this was using mirroring, but that's not available in the DXP, and is eventually being removed from the platform in favor of other strategies:
For moving bulk data (content items, content types, categories, visitor groups, etc.) between different environments, without touching code or the database, use the "Import Data" and "Export Data" tools within Admin mode. More information here: http://webhelp.episerver.com/latest/en/cms-admin/exporting-importing-data.htm
For bigger bulk migrations of data between environments, typically a database backup and restore is done between environments. Obviously, this is a bit more risky when involving a production environment.
If the content (or a content type change) is required as part of a deployment, you can build a content migration step. More information here: https://www.gulla.net/en/blog/renaming-an-episerver-page-property-using-a-migration-step/ and https://world.episerver.com/documentation/developer-guides/CMS/Content/Refactoring-content-type-classes/
If you are simply wanting to move authored content from a staging environment to production, it's suggested to create all content in production and use Episerver's Projects feature. More information here: https://webhelp.episerver.com/latest/en/cms-edit/projects.htm
If you are using Azure DevOps for CI/CD you might want to look into Epinova DXP Extension to Azure DevOps - that uses the Episerver deployment API but makes this easier to set up your pipelines. See https://www.epinova.no/en/folg-med/blog/2020/episerver-dxp-content-harmonization-with-epinova-dxp-deployment/ for more info.
Take a look at the Deployment API. There might be something in there for you. https://world.episerver.com/documentation/developer-guides/digital-experience-platform/deploying/episerver-digital-experience-cloud-deployment-api/
our test system has not been updated in some time, and its becoming a bit redundant, since the tickets are outdated. We use mostly Microsoft serves, but our Jira is on Linux so I need some help with the commands. I managed to log in via SSH, but I am stuck. Could not find a guide online including commands. Can anyone help me out? Thanks in advance.
Jira stores it's data in the JIRA_HOME directory and the database
If both systems are on the same version, all you need to do is to export the data from your production DB into your test system DB, and copy the contents of the JIRA_HOME to the JIRA_HOME on your test system.
If you're using the same type of DB on prod and dev, this should be trivial.
If you're not using the same type of DB, you should really should.
Good Afternoon,
I'm a little new to the Release Management Department and I've been tasked with converting our Release Management 2013 templates over to 2017. I've ran into a road block recently that I've been unable to figure out how to proceed, and wanted to consult the experts for tips or suggestions.
The most major issue is that Release Management 2017 doesn't offer the ability to setup Environment Tags, meaning I can't setup a "Production" environment and tag all of our production IIS servers in it in order to run a single command against all the servers. This hinders me greatly.
I've done research on this issue and have come to two possible work arounds. Either 1) Creating a release template for each IIS Site or 2) Creating a Release Template for each Environment (Test/Stage/Prod). The problem here is that we managed over 100 different IIS Sites and Databases, so creating an individual template for each site would be...astronomical. Whereas creating one bulk template for each environment could lead to issues down the line if we needed to release a specific site.
I figure that we are not the only company that work with this many IIS Sites, and that someone has to have figured out a better solution that the two above. Do we need to look elsewhere other than TFS2017 (With built in RM Features)?
I appreciate any and all advice on the issue.
The tasks you'd be using to target your servers (such as "PowerShell on Target Machines") take a list of servers to execute against. You can store the server names in a variable on the release definition at the environment level.
In TFS 2017 Update 1, you'll be able to store related variables in variable groups and share them across release definitions.
I am working on a SharePoint 2010 Server and i have following items in my SharePoint solution
Couple of web parts
State Machine Work flow (which will be integrated to an Infopath form library)
Infopath task edit forms
Lets say this solutions is deployed to http://[SharePoint201Server]:[PortNumber-x]/
This is the only server i have (No extra server for UAT), and what ever has been done so far needs to be given for user acceptance testing (UAT). I may create one more site at http://[SharePoint201Server]:[PortNumber-y]/ for it.
My problme is that how do i maintain two copies of my source code ? I will have to continue development on the same set of source code for next UAT release. I simply can not create simple copies of the source code as it will have same Assembly name and feature id, etc..As if i do so, any changes on under Development source code would affect UAT assemblies.
One thing i can do is to create seperate projects for UAT and Development with different Features and Assembly names, but is not that too much of an unneccesory work ?
What can be the best approach in such situation ?
i would suggest use sand boxed solution and create two site collection one for UAT and other for production. deploy your solutions individually on each sandbox solution. Sandbox solutions are deployed in bin not in GAC so you would not be having trouble code duplication
There is no best approach for this. You need to have different environments for development and UAT.
If the availability of machine is limitation, One possible solution is to have VM environment of the same machine for development and actual environment for UAT.
That obviously requires sophisticated hardware configuration to run both simultaneously.