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.
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
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.
I have the following scenario: The company edits aspx/xml/xslt files and copy manually to the servers in order to publish them. So, no build is done. For the sake of control we've decided to adopt TFS Preview since it tracks the version, who edited and so on. Needless to say, it works like a charm. :)
The problem is that since we are unable to build the apps we can't set a build definition to automate the copy of files to another place which, as I've stated before, is done manually.
My question is: Is it possible to copy the files to another place (a folder in a server or local) during the check in? If so, how? (remember, we don't build. so we can't customize the build process...)
You have two options.
1) Create a custom check in policy. I'm not familiar with this process enough to give you any pointers, but I believe it can be done.
2) Create a custom build template, and use that for your builds. You should be able to wipe the build template down to nothing, and then only add the copy operation to it. This is probably the route I would take. Get started here.
You mention you are using TFSPreview, which is hosted on the cloud so it won't be able to access any machines in your network unless you're prepared to open up your firewalls :).
You can copy source controlled files around the TFS Instance ([say into a Source Controlled Drop F1) and then check this out after the build completes.
Start by familiarising yourself with customising the TFS Build Process.
When you're up to speed, you need to look at adding a "Copy" Activity in the Workflow to move the files to the drop folder.
It seems that all of the initial Google results for "using subversion with xcode" are actually just tutorials for installing and configuring svn and Xcode, as opposed to actually using the two (i.e. interacting with svn via Xcode's GUI).
Is anyone aware of a good guide that teaches the tricks and pitfalls of working with svn via Xcode's GUI? Something that bridges the gap between the most excellent Version Control with Subversion book and the Xcode IDE (as in pure Xcode GUI without any terminal command use)?
Edit:
We all love our terminal commands, and we all love Eclipse but (and I mean this in the nicest possible way) neither is really the point of the question. I’d prefer to use svn via Xcode’s IDE instead of via terminal just as I prefer (well, for this case) to code in Xcode’s IDE instead of using vim and gcc. Apple engineers spent a good bit of time implementing that SCM menu in Xcode; someone has to have seen a usage guide somewhere.
I used this page as a reference for setting up my XCode projects with SVN. It is a good starting point, but I'll give a short walkthrough of what I did (since the page isn't really all that helpful!).
A couple notes: I'm using XCode 3.1.2 and Subversion 1.4.2. I've heard of problems with using SVN 1.5, but there are ways around that which I wont get into.
First off, I had a repository already set up and created the XCode project afterwards.
In XCode you need to set it up to know about your repository using the SCM tab in the preferences window. Enter:
A Name (this is arbitrary and used for reference with XCode)
The scheme (http or svn)
The host (i.e. svn.example.com)
The path (the exact path to the SVN repository located on the host)
The port (only if it isn't the default)
And a username and password used to access the repository.
The URL will be auto-filled as you enter the other fields. Hit "OK" when all the fields are good and XCode says it can connect.
Then open your project and do a "Get Info" (Round blue icon with an exclamation mark) on the project itself. Under the "General" tab down at the bottom is an option for SCM, select the repository you made in 1 and close the window.
Now open SCM in the menu-bar and go to "Repositories." Hopefully you've built your repository right using branches, trunk, and other directories at the base level because XCode doesn't have support for checking out the root directory. So go one directory at a time down the list and click the "Checkout" button and select a directory to check it out to (I recommend a "Code" or "Source" or "SVN" directory inside your XCode project directory). You cannot checkout multiple directories at once, but you can tell the next directory to checkout before the first has finished and XCode with queue the commands.
Once that is all done go back to your XCode project window and "Add -> Existing Files..." to your project. Select the directory you've checked out the repository to and I recommend using the "Create folder references" option instead of the "Recursively create groups" option because added and removed items will be automatically reflected in a Folder Reference but not in a Group.
Now you've imported your SVN repository into an XCode project. From here any time you make a change, simply Right-Click (Control-Click if you only have 1 button) in the file and at the bottom of the context menu are the SCM options for comparing, committing, updating, and discarding (reverting) the file. You can also use the SCM menu in the menubar for file or project-wide updates/commits/reverts.
I second the comment by the_mandrill, SVN support from within XCode is very limited, especially if you're used to Eclipse.
I also don't understand why everyone seems to need visual clients. I keep a terminal window open on my project directory and I have no problems interacting with SVN from the command line.
I know this is not quite what you asked, but I wouldn't rely much on the use of SVN from Xcode as what you can do with it is very limited. It's useful for being able to do a diff or annotate direct from the IDE but not a great deal else. I don't think it's any substitute for using a separate standalone client such as SmartSVN or Versions.
You also have to jump through a number of hoops to get Xcode to work with SVN version 1.5 onwards, so that's something to be aware of before installing a standalone client. If in doubt, check out a sandbox first.
Here is one of the best tutorials to configure subversion in XCode - http://iphonedevelopment.blogspot.com/2009/03/version-control-is-your-friend.html
It also teaches even to create repository in local MAC.
if you want to work with svn through a gui interface then i suggest you use eclipse + subclipse plugin (which have more features and much more reliable and easy than svn on xcode)..
you will work in xcode as normal but you will use eclipse only as an svn client (by creating a general project in eclipse and make it points to your xcode project directory )
and here is a tutorial of how to install subclipse
A lot of people have problems using the build in svn client, especially to get a new project into svn and that it works.
I created a straight foreward tutorial on how to do this, along with a very well known pitfall (works for Xcode up till the latest version of xcode incl. Iphone 4 sdk)
http://www.sodeso.nl/?p=599
I myself looked up for some good resources and one of the best I've found is a quite recent video from the WWDC 2012 :
Sign in here if it's not already the case : https://developer.apple.com/videos/wwdc/2012/
Then there is a video called :Session 411 - Source Control Management in Xcode
It explains how to use version control both with GIT and Subversion. It's really nice !
Hope it helps!
As has been mentioned in many other answers, the svn client with Xcode is quite weak (and that is being kind).
Personally, I think that running Eclipse just to get access to a svn client is a bit heavy handed.
I would suggest two answers:
Use a dedicated svn client for the Mac (Versions and Cornerstone are both very good, albeit not free... there are free ones, such as svnX)
If you are not wildly comfortable with the terminal, you can script a couple of the key commands that you want to use and add them to your Xcode user scripts folder, then you can trigger them from a menu item of from a keystroke, just as if you were using the Xcode native client. There's a ton of examples on how to do this available via Google.
I came across these - no idea how well they work, but wanted to add some resources if I could:
http://www.macresearch.org/tutorial-introducing-xcode-30-organizer
http://developer.apple.com/tools/subversionxcode.html
With XCode4 you can perform almost all of your SCM tasks from within the IDE itself, this is a great step forward.
Here is a link to the official guide :
http://developer.apple.com/library/mac/#documentation/ToolsLanguages/Conceptual/Xcode4UserGuide/SCM/SCM.html#//apple_ref/doc/uid/TP40010215-CH7-SW26
Unfortunately you still have to use the Terminal command line to add a new project to SCM, this is also clearly documented in the link above.
What it does not tell you is that you also need to manually add ignore instructions to your SCM configuration otherwise you are going to end up with user settings and build outputs in your repositories. I am currently figuring out the list and I will update this answer once I have it finalised.
PS :
I know this question is quite old now but I have added this for those of you who arrive here looking for answers like I did.
PPS :
Terminal command line increases probability of human error, takes longer, is more complex and is less transparent to end users. Overall the omission of being able to add projects to SCM from within XCode is poor design, I expected better from Apple who are usually good at simplifying UI. For the command line fans out there you might feel L337 but try managing a team of programmers and being responsible for their code, command line is not your friend.
I apologize for the length of this post but I needed to include a lot of information for proper answers. I hope this does not discourage responses...
Our shop historically has coded web sites using Classic ASP with some newer ASP.NET sites configured as web sites. As everyone knows this means that the source files (*.asp, *.aspx, and *.aspx.vb (or *.aspx.cs)) files are deployed to development and production servers as is.
The configuration management process was (and still is) entirely manual and includes the following steps (requirements):
Taking copies of the modified files and storing them in a "release" folder for archiving.
Taking copies of the production files that will be replaced and storing them in a "archive" folder for easier rollback.
Generating a diff report of before and after source files for code review or general reference when diagnosing a post-release issue.
The developer who coded the changes is not the person who performs the production release. The original developer is required to hand off the source files to another developer for some additional testing and production deployment.
To make the situation more difficult (not with the above..but with what I talk about below) we do not follow a formal release schedule. As individual bugs or enhancements are completed they are released. This means we could easily be making several releases to a site a week. It is even possible that a given site gets two different releases to individual pages on the same day!
Since I came on board I have been trying to transition the team to newer technologies like ASP.NET web applications and ASP.NET MVC. (We have also taken on responsibility for stand-alone applications and console utilities used for non-web processes...so my dilemma still applies.)
The difference between these technologies and the legacy technologies is the pre-compiling. Instead of deploying the code-behind files (*.aspx.vb (or *.aspx.cs)) a dll or exe gets deployed. This type of deployment package has raised several questions (issues ??).
Generating difference reports when the source has been compiled. While the newly modified source files are sitting on the developers system the production copy is a compiled copy.
Making sure that changes related to other bugs or enhancements are not included in the particular release. This would apply to both the original developer and the person performing the release.
Allowing the original developer to pass along the changed files to another developer for build, testing, and deployment.
Up to now I was the only developer on the team working on these types of sites and applications so the conflicts and issues mentioned above where non-existent. (I skip the difference report step and the I do my own deployments.) However, I am trying to push the rest of the team to embrace this plus allow for better distribution of bugs and enhancement tasks.
We are currently using VSS but I am pushing (and will most likely succeed) in getting us moved over to TFS. Some ideas I have are
Setting up a separate build system for use by the developer to do the deployment. This will solve two problems -- (1) Different versions/patches of Visual Studio and other libraries between developers and (2) instances where the person performing the release has checked out files locally for another change. (Of course this does not guarantee differences between the build system and the original developer but at least that means the release is from a consistent config.
Using labels to tag just the modified files. My problem is that while I can identify (and pull down for a build) the modified files, how do I identify the files that need to be included in the build but have not changed. Again, the idea is to not included checked in files that are related to un-released changes.
Using labels to tag all the files for the release (the modified files and the unchanged files). My problem with this is similar to the last one...how do I make sure that a file checked in by another developer (say they went on vacation) for an un-related change is not labelled and included in this build.
Using the labels I could probably write a script to generate difference reports for the labeled version and the previously labeled version. If the process works properly that should result in exactly what changes are included in the the particular release..?
Any other ideas, concerns, points of interest? While I do have some flexibility of the process some of the requirements (like difference report or some way to easily view differences and having separate developer/deployer) are most likely untouchable.
Thank you so much for any help you can provide on this.
To keep track of different versions of the code and to help you manage very fast release cycles (daily) vs long term enhancements you can use branches in TFS.
There is a ton of information out there on branching, but in general I like to try to keep things simple. For example, have one branch called "release" and another "development". Everybody works on the development branch but the code to be deployed to production is merged into the release branch right before release.
This blog post describes the process:
http://team-foundation-server.blogspot.com/2008/01/how-we-branch-our-code-in-tfs.html
Well, based on my experience with VS2003 vs VS2010 for example is that the project structures are different and allowing VS to do a conversion often times results in a solution that either requires a lot of refactoring or is unusable. Having said that; if you can transition everything over to TFS2010 then one way to handle it is to setup different projects for each solution and use the TFS built in version handling for the different releases. You can also set up a build server and schedule nightly builds. If the build is ok then you can push this version into testing and ultimately production. You should really read up on TFS because it's totally different from VSS and is definitely a huge upgrade in allowing you to do team-focused development.
P.S. TFS has a really good Sharepoint integration which will help you and your team keep track of all the bugs and tasks.