As far as I'm aware it should do this by default but whenever I start a play2-mini app it runs in Prod mode (so I get no code reloading etc).
How do I specify I want it to run in development mode?
'play run' is the command for running the play application in development mode. Though it is too older question, i am replaying for others reference.
Related
Basically what I have is my frontend (Vue) and my backend (Node.js and etc.). By following a guide, I've built the frontend for production using npm run build. I got a bunch of files in a build folder I setup within a previous step. These files were then moved to a folder in the backend. It works, but it's more a demo than anything else, and the frontend and backend will have to be modified more as I continue.
I'm just wondering if and when I edit the fronted more (let's say, when I add a new page) am I supposed to go through this process again? So I'll modify the front end folder, build that, move files, etc.
Thanks.
Yes, definitely.
If we are in a development environment, we use npm run dev or yarn run which upholds the development environment running and updates the browser whenever any modifications inside the code happen. We don't use any final build in the development environment because we make code modifications so repeatedly that it would be a sore process to make a build after every modification and check the results using that build.
But, the production is distinct from the development environment. We deploy the only code which is bug-free, entirely working, and ready for users to use. Deploying to production means all changes have been made, and the final code is ready to be deployed. So, we make a final production build and deploy it to our server.
So, don't panic to deploy to production every time you make a small change in the code. First, complete your all changes, and test the changes in the development environment, if everything is working correctly then only create a final production build, and deploy it to the server.**
I hope this helps.
I working on a Google Sheet Add-on. When testing the addon [from the legacy editor Run --> Test as add-on] and selecting "Test with latest code" sometime it does not run the latest code (I know this because I've made changes to the code and error messages are pointing old line numbers).
Saving a version number and specifying that in the test screen doesn't seem to help either.
Turns out the problems was that parts of my "Test" Add-on was running from my production deploy add-on NOT my test code. This was super confusing and took a long time to understand.
I knew that "Installable Triggers" (aka onOpen) cannot be installed or tested via editor (you will get error message when trying to install them) but thought "Simple Triggers" did work since the onInstall work and runs when testing an Add-on. However this is not true, other simpleTriggers - such as onEdit - will not run in test mode.
My test spreadsheet had magically enabled the deployed Add On [you should have to manually enabled addon to be available for each spreadsheet] so onEdit event were running creating log messages right next to development code messages - super confusing!
To avoid this problem, I completely uninstall the Production Addon from my account. Not ideal since I'll have to re-install it to test production deploys.
Also I had to rewrite my trigger code so it could be tested manually via menu bar (since the "even object" isn't available) otherwise you must deploy your code every time you want to add a debug statement.
I hope this save someone some head banging!
Should end to end tests be run at build time (running the application on the build server), or after deployment? I have not yet found a solid answer for which one is the standard.
Edit
I mean after deploying either to QA/SIT/UAT etc... vs. just running it on a build server without fully deploying it.
The whole point of having a build server is to create a single build of the current source code, of which you run tests and make sure that things work before you deploy them. I don't know why anyone would want to run tests after then have been deployed. What happens if you find a bug? You going to roll back the deployment? Always test before deployment.
Ideally, you would have a build environment that mimics your production environment that will allow you to run tests in a "deployed" environment. It's the reason that you have a development/staging/production servers.
While I only have a github repository that I'm pushing to (alone), I often forget to run tests, or forget to commit all relevant files, or rely on objects residing on my local machine. These result in build breaks, but they are only detected by Travis-CI after the erroneous commit. I know TeamCity has a pre-commit testing facility (which relies on the IDE in use), but my question is with regards to the current use of continuous integration as opposed to any one implementation. My question is
Why aren't changes tested on a clean build machine - such as those which Travis-CI uses for post-commit tesing - before those changes are committed?
Such a process would mean that there would never be build breaks, meaning that a fresh environment could pull any commit from the repository and be sure of its success; as such, I don't understand why CI isn't implemented using post-commit testing.
I preface my answer with the details that I am running on GitHub and Jenkins.
Why should a developer have to run all tests locally before committing. Especially in the Git paradigm that is not a requirement. What if, for instance, it takes 15-30 minutes to run all of the tests. Do you really want your developers or you personally sitting around waiting for the tests to run locally before your commit and push your changes?
Our process usually goes like this:
Make changes in local branch.
Run any new tests that you have created.
Commit changes to local branch.
Push local changes remotely to GitHub and create pull request.
Have build process pick up changes and run unit tests.
If tests fail, then fix them in local branch and push them locally.
Get changes code reviewed in pull request.
After approval and all checks have passed, push to master.
Rerun all unit tests.
Push artifact to repository.
Push changes to an environment (ie DEV, QA) and run any integration/functional tests that rely on a full environment.
If you have a cloud then you can push your changes to a new node and only after all environment tests pass reroute the VIP to the new node(s)
Repeat 11 until you have pushed through all pre-prod environments.
If you are practicing continuous deployment then push your changes all the way to PROD if all testing, checks, etc pass.
My point is that it is not a good use of a developers time to run tests locally impeding their progress when you can off-load that work onto a Continuous Integration server and be notified of issues that you need to fix later. Also, some tests simply can't be run until you commit them and deploy the artifact to an environment. If an environment is broken because you don't have a cloud and maybe you only have one server, then fix it locally and push the changes quickly to stabilize the environment.
You can run tests locally if you have to, but this should not be the norm.
As to the multiple developer issue, open source projects have been dealing with that for a long time now. They use forks in GitHub to allow contributors the chance to suggest new fixes and functionality, but this is not really that different from a developer on the team creating a local branch, pushing it remotely, and getting team buy-in via code review before pushing. If someone pushes changes that break your changes then you try to fix them yourself first and then ask for their help. You should be following the principle of "merging early and often" as well as merging in updates from master to your branch periodically.
The assumption that if you write code and it compiles and tests are passed locally, no builds could be broken is wrong. It is only so, if you are the only developer working on that code.
But let's say I change the interface you are using, my code will compile and pass tests
as long as I don't get your updated code That uses my interface.
Your code will compile and pass tests as long as you don't get my update in the interface.
And when we both check in our code, the build machine explodes...
So CI is a process which basically say: put your changes in as soon as possible
and test them in the CI server (it should be of course compiled and tested locally first).
If all developers follow those rules,
the build will still break, but we will know about it sooner rather than later.
The CI server is not the same as the version control system. The CI server, too, checks the code out of the repository. And therefore the code has already been committed when it gets tested on the CI server.
More extensive tests may be run periodically, rather than at time of checking in, on whatever is the current version of the code at the time of testing. Think of multi-platform tests or load tests.
Generally, of course, you'll unit test your code on your development machine before checking it in.
currently all my application that is released is always release in production. However I would like that changed and also have a development side (For testing).
I've tried searching for steps on how to create a development server however I cannot seem to find a tutorial.
In the past I've seen someone release their application in development by having it in on "Debug" option and have it released in production by having it on the "release" option. (I apologize for the vagueness as it was along time ago since I saw it).
But anyways to my question, can someone tell me the general steps for creating a production and development environment for my project? I'm currently using winform application on VB (Microsoft visual Studio 2008)
Thanks for the help
Your development environment should be an exact copy of your production environment. Typically this means buying a duplicate set of hardware, duplicating a production disk, and running that on your local dev/test lan. From there, you can set visual studio up to do a few different things:
1) build > configuration manager > debug (or optionally the build menu bar) to be able to debug your application with your IDE
2) set up remote debugging to your new dev / test server - project > properties > debugging > change local windows debugger to remote windows debugger and fill out the blanks. You will also need to install msvsmon on the dev or test server.
3) copy your assemblies to the remote box - do this manually, OR - project > properties > build events > post build events > add a couple command line copies to get your exe and dlls over to your mapped server. Don't forget to use environment variables and macros to make your life easier.
4) finally press play like you probably used to do in the IDE, and you should see the application fire up on the remote box.
I'm not sure I entirely understand your question, but I believe that if you are trying to build a testing/staging server for testing your software prior to release, then this should be an exact copy (if possible) of your production server (this allows you to iron out any environment specific bugs).