I just want to know something about Katalon Studio. I have not worked in automation testing before but now I have some assignment about testing in Katalon.
My client wants to test in Katalon but his requirement is that he wants to run test cases on every build automatically and he also doesn't want to install Katalon IDE or any library he just want reference so that he just added that reference on every build so that all the test cases run automatically on every Dev build.
Is this possible using Katalon? Kindly help me, please. Thanks.
You have to establish full CI Pipeline for your requirements. My advice is, to use Katalon with Jenkins and your developers code repository (perhaps GIT or SVN). Than you are able to implement a server/slave pipeline, where you can execute your Katalon scripts on slave, every time DEV builds.
See:
Katalon/Jenkins Tutorial
I am developing a meteor application. I noticed that the meteor server sometimes suddently crashes, this makes me think that it might not be optimized for production.
In a production environment, should I consider to add/remove some packages? Which one? And what are the best settings? I just want to make sure to have a reliable server that stay up all the time.
Have you taken a look at meteor up yet? It will set up a production quality server for you. I've used it for several production applications and it works great.
As far as adding/removing packages goes, I've never ran into any problems with installed packages running on production. A couple of my apps have about a dozen or so packages installed. But if you suspect that a package might be causing the problem, I would go to atmosphere and search for your packages and make sure that they haven't been flagged. You'll see a bright red flag next to the package name if it's been flagged by the community as "not working".
Maybe also check for issues on GitHub.
If you do decide to use meteor up, after your app has been uploaded to the server, you can check the log s for any problems.
mup logs -f
We use artifactory as a repo manager. We store packages for releases in repo libs-release-local and snapshot packages in libs-snapshot-local.
For example: If we send the war (web app) into test, it should be from libs-snapshot-local and if it is into stage & prod it will be from libs-release-local.
I will say a scenario, where I needed help below:
Once the war is certified good on test server we would send the same code to stage.
We saw a bug after deployed into stage, so we changed the code and again build it, it obviously cannot go to same versioned release(as in artifactory, we cannot override releases).
So,
What will happen if we recognized 10 bug fixes one at a time, after each deployment in stage ?
What if we have realized there are bug fixes after going to prod.
Artifactory will have bulk of folders with so many version names & folders. Is that good practice? Or else anything senses wrong in our procedure?
Thanks!
Suggest to read Binary repository management Refcard first.
You need define your strategy for your folders and wars (web application), it is already good to use different repo for different purpose (snapshot/release)
The process for maintenance is simple
fix the bug and increase the version, send to the libs-snapshot-local for testing
after testing, a.k.a QA passed, the packages are promoted to release/stage repo libs-release-local again for public use again.
In this case, bug fix is the same as normal development procedure.
or you can refine the questions to make your questions more clear.
We have a number of config transforms which enable us to publish to a particular environment with the correct options specified in web.config.
However, it would be useful to run the application locally while specifying a particular build configuration. This would enable us to run the app locally and have it connected to the live database, for example - quite handy when tracking down bugs, for example.
However, when we press F5 to run the app locally, regardless of the build configuration currently selected, no transform of the web.config file appears to occur.
Is this the normal behaviour and is it possible to change it?
Reposted from comment:
Yes, it is the normal behaviour. It's a nuisance because it makes the whole thing feel half-a-job-ish and I agree there should be the option to opt-in for the same transformations being applied during a standard build. I haven't found any VS extensions that can do this for you yet, though I imagine it could be done. I personally make a ".Local" version of all my build configs and publish to a local IIS which I can attach to very quickly/easily if I want to use a diffferent environment/config's web.config. Requires some duplication, but does the job
Thanks David
I have a Windows 2003 Server with IIS, I installed VisualSVN Server on it.
I have two developers, who are going to use TortoiseSVN.
Since this is my first time ever setting up a SVN server I am kind of confused on how this will all work. The way I see it, each developer would have a copy of the repository on his or her local pc, would each person be required to have IIS installed on their PC as well to test their copies before checking out?
Should I create a testing folder on the server and then a production ready? It seems as if that would cause more issues with copies?
What would you do?
EDIT
I dont know what I was thinking, I forgot that VS has a built in IIS when you debug so the issue about setting up IIS on either client or server is now a non-issue. But I am confused, I imported the site into the repo, it said it was on revision 2 but I dont see any of the files in the repo folder. Do I create a virtual folder in IIS pointing to the repo that I created?
No, each developer uses your repository, and checks out their own copies to do their work. They do not need IIS or svn, etc, installed on their systems.
I recommend reading up on the Subversion FAQ.
Your devs don't have a local repository, they have a Working Copy on their PC. Typically, this is the most recent version of the app with whatever changes have been made by the developers but not committed yet.
As this is a web app, then your developers will need some kind of web server locally to test it - this could be IIS, or Visual Studio's built in web server (although that does behave differently to IIS in subtle ways).
You said in a comment: "My problem is I dont want the devs to commit to the live site in case there was a bug.".
The devs commit to the SVN repository on the server: at some point you will want to export (aka 'publish') a copy from the latest version in your repository to your live site. In order to make sure this works, you can check out a specific version from the server, test it, and if it passes the tests upload it: devs will always check in code with bugs (even though it builds) as it's better to check code in frequently than build up lots of changes locally then commit them, as there are bound to be conflicts with work other developers have done.
Branching and Tagging are useful concepts here: when you have a version which is almost right, you 'branch' it away from the main 'trunk' of the source code tree, fix any issues in the branch (back-porting to the main trunk as required), then when you have a working version you 'tag' it (as version x.y.z) and upload it. This way you can always refer to the particular version of the code you have uploaded, which makes it a lot easier to identify bugs which turn up in production. As others have suggested, read the SVN documentation for more info.
It depends on how you work. There are other discussions about folder structure and such which play directly into how you use version control.
Uh, no, no local repositories. Setting up SVN is easy, well almost. You'll want to look for the svn windows installer and set it up on the server. You'll want to install Apache and then you'll have a little hurdle setting up the http.conf file to expose svn over http. There's a little complexity with setting up security so go with Windows Authentication, you'll need WebDav, google it.
Once that's done, any svn client can hit it and checkout a copy and work with SVN normally. If you get really stuck, comment here and I'll go get a copy of our install and config for you.
The good news is that it's rock solid, once you get it setup it'll run forever.
"Pragmatic Version Control Using Subversion" and the SVN red-bean are the two sources you need to see.
Set up SVN on a single server and have all your developers point to it.
I've installed tortoise on the server and do Updates / Checkouts of the release website. Some people don't like checking in compiled code, but I like having the production compiled site in SVN.
If you use tortoise on the server, Do the initial checkout to the inetpub/website directory and then on rollouts you just need to update the directory using tortoise->update
Of course checkin to rollout is considered bad practice without first rolling out and testing on staging servers, but depends on your team size.
I have used the following resources for learning SVN:
http://www.polymorphicpodcast.com/shows/subversion/
http://www.dimecasts.net/Casts/ByTag/SVN
Found both quite good, and learning by watching can be easier especially for getting started.
No - your central server will maintain the repository. Your developers will get copies of the repository, make changes, and then commit them to your repository.
You actually have quite a few things to figure out if you want to do a successful deployment of subversion.
One really good article about setting up subversion on Windows - https://blog.codinghorror.com/setting-up-subversion-on-windows/
No, SVN server must be installed on a single computer. Each developer point at this computer and get locally (and eventually) a full copy or a partial copy of the repository.
You may also buy a book from O'Reilly about Subversion. Don't remember the title, sorry, but it helps me a lot.
All the best ! Sylvain.