is there a way to backup a JIRA project configuration and then restore?
The issue I have is that sometimes doing workflows changes I can break the whole configuration.
So, I'm looking for a way to easily rollback to the previous working version of the project configuration.
Please note that I cannot rollback the whole JIRA server as it will affect other projects.
We are using the latest version of the Jira Service Desk on premises.
Thanks,
Please, see full answer here.
You can't.
JIRA does a full export of everything, and you can import
the issues from one project from that. But that's it. If you need
single project backups with configuration, you'll need extra
functionality. This is exactly the case where I would reach for
Botron's tool -
https://marketplace.atlassian.com/plugins/com.botronsoft.jira.configurationmanager
Whenever you publish a change to a workflow, JIRA asks you if it has to save a copy of the original. If you do that, it should be easy to revert to a previous version. Still it gets cumbersome to manage lots of copies of a workflow and to understand what changed when.
If you want a bit more control, you can also export your workflow to xml and keep that somewhere. If you need to rollback, you can import from that xml again. For more details see the documentation here.
If you want even more control, then add-ons like Botron's configuration manager can indeed be useful.
Related
I am interested in any information about or experiences with deploying PowerApps solutions to new environments within the same tenant.
In my solution I have a canvas-app and several flows between the app and sharepoint. I have used connection references to all connections (sharepoint, mail, etc.). On the devops side I have a build pipeline from my development environment, very much in line with Microsoft's recommendations for ALM. In addition, I have a release pipeline to publish the solution in another environment, e.g. a test environment. I can publish the release but when I access the solution in the new environment all flows have been turned off and all connections to sharepoint have been severed. When I inspect the flows it throws an error that it was unable to locate the connection Id. What strikes me as odd here is that the connection references that are visible in the new solution cannot be selected. However, what I can do is to add a new connection (from each flow), whereafter I can turn the flow back on and activate each of them in the canvas app.
What I am asking for here, is any documentation, guide, tutorial, help, etc. to make this release a little more automatic, so I won't have to re-add connections for every single action from each of my flows.
I think you are in luck 😊 and you should check out the latest PA community call. I think the last demo is the thing you are looking for (especially from that moment I suppose🤔) and is now one of the targets in Power Platform.
If you are considering to introduce source control as well (like git), currently there is a cool experiment going on in the community in that direction which I think is quite promising and you may check this article. But please consider this pack/unpack tool as an experiment and don't just remove the original .msapp files yet 😉.
I think I have finally found a working solution. I'll document my steps here for other ALM hopefuls.
When pushing to the target environment for the first time I need to click on each of the connection references, click on solutions layers, ) use the breadcrumb path to go one step back ] and from here I can assign the correct connection. Subsequent deployments now work without any hassle.
Also, first time deployment, I have learned cannot activate workflows. However, future deployments can activate workflows by managing the setting the the Import Solution build tool
I'm in the process of migrating some source code from an in-house system over to TFS 2015. I'm using the APIs via Microsoft.TeamFoundation.VersionControl.Client etc libraries.
Ideally I would like to also import the history of each item including who made the change and when.
The workspace.CheckIn method allows me to specify the "author" who made the change, but I don't think it's possible to supply the when.
Does anyone know if's it possible to "back-date" a checkin?
You can't change CreatedDate of a changeset. In fact you should not be doing this in the first place.
Even if you manage to change somehow then you will loose the track of when you really created/check in the changeset on TFS.
If you are upgrading older TFS to TFS2015. Which is a full data transfer. TFS sever will also include the back-date changeset. However you are using an in-house system, just the same as checking in code from local development.
So you may have to manually manage the source control history of your in-house system, such as import to a Excel.
I am creating a web app in Erlang with n2o. My current dilemma is the automatic syncing of changes i make to the app's source code to that with the accommodating release.
For example, I startup my app release in the erlang console, go to specific localhost:? address and see index.erl being reflected in the page with <span>Hello</span> shown. I then go back to modify the index.erl file to say Hello World instead. The changes are not reflected. So i end up regenerating a release to see the new changes.
I guess I could write a bash script to synchronize changes between the app source files and the release libraries, but I imagine there must be better ways of doing this.
What is the appropriate way of doing this?
The synchronization capability you're looking for is explained in the n2o README.
Clone the git-repo 5HT/n2o and follow the instructions in the samples section of that repository. Make a change to one of the source files and once they are saved, you can see the updated changes in the erlang shell as well the web site itself.
I am using Visual Studio Online. I have projects which have common code that I use across a number of different solutions in different TFS projects and I also have some files which are linked from other TFS projects in some of them. In order to be able to access them all, I've changed the Workspace config so that I have just mapped $/ to a particular folder.
The problem is that I just checked in a change in one project and noticed that it also checked in a change in a completely unrelated one that wasn't part of the solution at all! How can I configure things to be able to access everything that I need to without cross-checking-in files from unrelated projects (and without having to manually exclude/include files in every check in)!?
EDIT: I've noticed that this doesn't seem to have happened again on my last couple of check ins when I also had items from other projects checked out. Wondering what caused it.
You should look at a NuGet solution for this. If you are using VSO you can use the new MyGet integration with an automated build process. If you create an automated build for the shared project output that is packaged in a NuGet package you can create a NuGet repository ion MyGet to provide it to your other solutions.
Once you have that, if you then change the shared code and check in, the build and package will kick off and deploy your new version of the package. Your other solutions will then prompt you to update automatically. You don't even need to check in the dependent assemblies as you can use NuGet Package Restore to make sure your local and build server get the right versions.
It sounds like a lot of work but once you get up to speed it only takes a few hours of investment to configure for anything you want to share or deploy in this way.
In the Pending Changes section of Team Explorer, in the Included Changes section there is a drop down. If it's set to "Show All" you'll see changes pending for all your solutions. If it's set to "Show Solution Changes" you'll just see changes pending for the current solution. (My guess is that it was set to "Show All" when you checked in your changes and that's why you got changes from other solutions checked in.)
I would like to get the issue list from Bugzilla and JIRA for an open-source project. For each issue, I'd like to collect the corresponding compilation units(for java projects, class/or interfaces files), which may relate to the issue.
Any idea on implementing this feature would be appreciated.
Many thanks!
For JIRA, there are some solutions out there you could use out of the box. See the documentation to integrate with source control for JIRA how to do it. This only works for some source control systems, you should which ones are supported. This gives you a list of change sets (e.g. for Subversion) for each issue.
Another approach could be to do it on your own through an interface to the source control system yourself. The following prerequisits have to be in place:
Your developers have the tools to add the information which issue was worked on by which commit on a per commit base.
You have rules that changes to the sources should all the time being done only for one issue at one time.
You are able to parse the additional information you will get from your version control system e.g. by a script or a program.
For Subversion and JIRA, it could work like that:
Ensure that all commits are only done if the Subversion commit message contains at least one JIRA ticket number. You may even ensure that by a pre-commit hook
Learn how to get the following information from the subversion log
The ticket IDs (by parsing the message) for each change set
The files that had changes for each change set
Collect for each file all tickets.
Show them in a format you like.
I think that this is not too useful, because ticket per class is too fine grained. Perhaps you should have a mapping of the files to modules, sub-projects, ... and collect tickets for them.
All solutions will be different depending on your selection of tools. JIRA and Subversion are here just examples :-)
The best way is to first integrate your issue tracking system with your source control. That means that whenever a developer commits a new change, it determines the set of issues related to this change. This linkage is managed by your issue tracking system and it can show you all the source files, resource files, config files that have changed in the context of an issue.
This info, will be available through the api of that issue tracking system as well.