Many software development teams use the term production to refer to the live environment accessed by their users. Rails for example uses this nomenclature. The string production is also used by express.
The dictionary definition of production however doesn't seem to easily lend its self to this usage. Is there an alternate definition I'm missing, or did some earlier project establish this standard?
In a factory, the "production line" is where the actual product is made (or you could say "the goods are produced")
Hence "production" is "where we make the thing we sell to the user". Move that idea to comapnies where the thing being sold is a service and the principle holds...
Related
I have some experience developing in the xs classical apps in the SAP Cloud platform neo evironment. And plan to migrate to xsadvanced in the cloud foundary landscape. I have a few fundamental doubts which sadly i could not get answers to even after reading the documentation.
If i understand correctly XSA is cloud foundary extented by SAP to support SAP HANA 2.0 as a service via the HDI Container, allowing the tradional xsjs to run as a node.js container and bunch of other SAP specefic serivces ?
the MTA (mutlti target application) development promoted by SAP looks neat however i have a few questions when it comes to working in a env where multiple developers work with the same MTA in the "dev" space for example.
the typical MTA is combined of a web module where the UI part resides , node module to hold the services and a db module that is the entire HDI container which holds tables,views and the actual data .
the developers dont work with WebIde and use VSS code and cf CLI.
Question 1 : if i want each developer to have an isolated MTA when developing , then each developer must push the same MTA app with a different name when he works with works for some feature development ? (preferably some feature brach that gets pushed as a new app) . every line of code change then needs a push to CF
Question 2: Pushing the app with the same schema name in MTA file creates a new schema for the second developer in the same HDI cointainer (i am not sure if this correct however this what i understand from : here
But the second schema will remain empty and many not contain data, do we then take care about data replication from schema 1 to schema 2. wont this explode the space usage ?
As i said, i did not find documentation about how multiple developers can work on the same MTA app in the shared space so any guidance will help
thank you
Multiple developers are able to work on the same MTA app, because of git functionality and different workspaces dedicated for each developer. More to that, you can even personally have even more that one workspace, which means you can have different features developed by yourself separately.
When you build your container or run your application in your space, each time get a unique schema name or application url, this means you can work independently.
A bit tricky part is when you want to join your commited code with other developers. Basically, it depends of how big your project is. If you have a large project, it's better to control merges using Code Review and Unit tests, or maybe you are in a small project and work on different files, which means you can merge your code easily to master branch by yourself.
Reading odoo API or source code your would encounter the term ir ( usually as a prefix ), I can't seem to figure out what does it stand for ?
for example
ir_sequence
The meaning is Information Repository.
Although there's no official statement on the matter AFAIK, I tend to think about it as Internal Resource (various resources the system needs to work fine, but not actually meaningful for normal users day-to-day work), just as I think about the res prefix as Resource (which is not internal, it's for normal usage).
As example, res.config is to create visual configuration wizards to be presented to a user that may not be the sysadmin (he could be just the sales responsible for example), but many settings are actually stored as ir.config_parameter records, which are only accessible for the sysadmin and are used extensively by Odoo internal code.
I have read several articles about creating a Sharepoint Developer VM. They all say to "sysprep" them. Why (exactly) must the sysprep be done? What kind of problems (and why) will we run into if we don't sysprep them?
(I suppose what I am asking is, what would be the difference in doing "sysprep" and just bringing up the VM, changing its Name/IP, reboot then install SP?)
I've had success in the past with just copying Hyper-V vhd's as a method of cloning VM's - however, I now use sysprep when cloning any of my machines as it's been mentioned as a best practice in many places. And, it does some nice things like allowing you to cleaning up a bunch of stuff that I don't want to duplicate and letting me choose a new name for the machine on boot. From MS Sysprep Technical Reference:
Sysprep prepares a computer for disk
imaging or delivery to a customer by
configuring the computer to create a
new computer security identifier (SID)
when the computer is restarted. In
addition, Sysprep cleans up user- and
computer-specific settings and data
that must not be copied to a
destination computer.
And you may want to read Russinovich's post on The Machine SID Duplication Myth (and Why Sysprep Matters) for more good explanation of how SIDs work and the very last paragraph has another reason for going this route:
Note that Sysprep resets other
machine-specific state that, if
duplicated, can cause problems for
certain applications like Windows
Server Update Services (WSUS), so
Microsoft’s support policy will still
require cloned systems to be made
unique with Sysprep.
Good luck!
What is a good naming conventention for web role-, worker role- (and vm role) projects in Visual Studio( 2010) ?
(edit):
And what about the deploy ? The name of the web role will affect your deployed app named in the Cloud....
I don't think it matters a lot. Number of roles in the project is usually very small. Oftentimes, the web and vm roles maybe user-visible via URL's, (blahblah.cloudapp.net). So I would name them by functionality and ease of reading and not prefix them or post-fix them with a special "worker", or "web", or "vm" keywords, as you are probably thinking.
Its entirely arbiratry(sp). And unless you're adding a degree of automated monitoring and management doesn't have any significant impact.
My personal preferrence is to name them appropriately based on the unit of work, following whatever naming convention is appropriate for your shop.
The bigger question is the management of services and subscriptions, which gets a bit more complex.
I'd suffix them with ".Web" or ".Worker". Visual Studio does something similar with Silverlight projects, if you let VS generate your Silverlight host app.
There are parameters that I would not want to be transferred from production environment to QA system. Staff like network path and url's. The problem is that in ABAP everything is in the database and when the database is copied to the QA system you have to manually change those parameters. And this is prone to errors.
Is there a way to store configuration information in a way that won't get transferred with the database?
Thanks.
In short: no - at least that would be very unusual in a SAP environment.
If your QA system is set up as a system copy of your production environment (which is the usual path), there are quite a few steps to do to make the system work correctly. This includes some configuration, which can be as simple as filepaths such as you mention, but also the addresses and names of "partner systems". For example, one of my customers is a bank, so when copying his production system, he makes triply sure that no activity on the QA side accidentally trickles to the production side. Some other changes are made as well, for example obscuring peoples names and addresses so no mail gets accidentally sent etc.
There are a few ways to make applying these changes as easy as possible (look for some SAP documentation or books on SAP Transport and Change management, I had one by Sue McFarland Metzger or so that was quite good). From what I've seen, there is usually a set of transports that change the configuration and customizing etc. on the QA system to the
appropriate values.
Hope that helps.
You cannot prevent the configuration stored in the database from being copied to the cloned instance. However, you can design the configuration storage in a way that will prevent the copied entries from being used. You should check with your basis administrators if they can guarantee that the cloned system will get a new system ID (SID). If this is the case, then you can simply use the SID as key field in your configuration table. After the system copy, the SID will be changed and the cloned system will no longer access the original entries.
your question is not clear, are you talking about standard or custom config ?
Greetings, assuming you are storing these paths in a Z table, then some shops put the sy-sysid ( system id ) as one of the columns. Maintain all systems in your dev and transport to production. This becomes painful after a while, so I would only suggest this for information that does not change a lot ( file paths might be good ).
T.