AFAIK staging deployments are intended for testing Azure roles which implies that I could deploy a role with errors in code into staging. If that error damages my data I could be screwed.
How do I address that? I can't stage a role without reasonable data (hard to test it) and I can't let an unstable role damage the data.
Do I have to maintain a separate dataset for staging? How is this problem typically solved?
AFAIK staging deployments are intended for testing Azure roles which implies that I could deploy a role with errors in code into staging. If that error damages my data I could be screwed.
Staging is really designed to be a place for deployment - for spinning up new role instances prior to the instant virtual IP address swap. While you can do some testing there - e.g. making some final checks that your deployment is valid - it's not really there to allow you to do lots of testing.
How do I address that? I can't stage a role without reasonable data (hard to test it) and I can't let an unstable role damage the data.
I've generally tested on a development environment with fake data or deployed as a separate Azure service with fake data. However, I admit this has never been in the situation where I've needed huge amounts of data for testing - generally these tests have been test deployments with just 1 or 2 users.
Staging, as an environmentis meant to acurately simulate your production environment, including the data.
We have the following strategy: production is production, staging is connected to the same DB as staging, because the updates in Azure work the way they do; meaning I want to be able to upgrade my staging deployment, give the client a chance to verify again, and then swap the VIPs for the deployments, thus transitioning the application seamlessly. For those times, when there are breaking changes in the database, we decided to either create a new deployment alltogether, or turn-off the production one, giving users a maintenance notice.
Ultimately it's whatever you decide. But again, bearing in mind what Azure's staging is, I'd suggest keeping the data real, and consider it a beta access "program". Unless of course you have other requirements. But that's besides the point.
Related
We have a payroll system where users input their worked hours. There is a database of users with names, emails, addresses, input hours etc. We want to transfer that data to preprod for testing purposes.
My question is: How should we go about transferring personal data in compliance with GDPR? Should we absolutely replace the user data or there are other ways?
Does the data in a preprod env has to be absolutely equal to the data in prod, if that isnt the case you can use a library to fill your preprod database a library like faker can do the job.
Concerning GDPR, if the both database are hosted by the same service, same server same timezone, you are not breaking in rules but if a user that requests his data to be removed, it has to be removed in Production and Preprod env.
A pre-production environment should by definition be as near as humanly possible to the production environment. As long as you have the same privacy protections in that environment as in the production environment (restrictions to need-to-know, ability to extract data at request, ability to purge data at request, and so on), I don't see why GDPR should be a hindrance. You need to have measures in place to ensure the data-in-motion part doesn't fall into the wrong hands, of course: sometimes, encryption actually is the answer to security issues!
IANAL, of course: there sometimes seem to be about as many interpretations of GDPR as there are citizens in the EU…
I would like to have certain workflows run on a different schedule in staging and in production (ex: one workflow run multiple times a day in staging and only once a day in production). Doing so would help with getting quicker feedback on the runs and also save on compute costs. How can I do this with flytekit? Is it recommended?
There is no easy way to do this as it goes against main integration/deployment strategy championed by Flyte.
Flyte entities, comprising tasks, workflow, and launch plans, are designed to be iterated under in a user's development domain. After iterating, users are expected to deploy that version to the staging domain and then to production. The more difference there are between those domains, the more confusion there will be down the road we suspect.
That said, it is possible to do this because the registration step allows the user to specify a different configuration file. One of the entries in the configuration file is this workflow_packages construct. This enables the user basically to look at different folders when registering in staging vs. production for instance.
In order to get a launch plan to only exist in one domain, you'll need to put it in a new folder/module that is inaccessible from any of the extant workflow packages, and then put the other one in yet another.
In the staging file,
[sdk]
workflow_packages=app.workflows,staging_lps
In the production file,
[sdk]
workflow_packages=app.workflows,production_lps
In a common continuous-delivery process, the code is moving from a development instance to a staging instance to production instance.
For development purpose (reproducing bugs, testing performance with a full data set), most of the time developers fetch data from production database to their development environment. See, for example, this question.
In my company, we use three instances beside production in our continuous delivery process:
latest: sync every night with our SCM trunk
staging: with the last released version before deployment to production
stable: with the exact same version of the software deployed in production (useful to reproduce bugs found on production)
The problem is that on the stable instance, for reproducing bugs we would like to have the exact same data set that is on production. So we would like to sync databases on a nightly basis.
Is it a good practice ? How to implement it ? Any pitfalls ?
Depending on the data you have in production, you may not want to replicate it back to non-production environments. (Or may not even be allowed to under certain regulations.) If you have customer data, personally identifiable information (PII), regulated data, financial data, credit card data, health data, SSN, or any other type of sensitive data, if you replicate it you need the full controls you have (or should have) in production - which you probably don't, and probably don't want.
There are several VDB solutions which I recommend you to look for.
One of them is Delphix
Windocks supports containers with integrated database cloning, and is used for just the use case described. Full disclosure, I work for Windocks.
In an n-tier web-app, should I be running integration tests against a different database, one dedicated to testing the code? Is it standard practice to test against the production database as well?
You should never run untested code on production. After all, you don't want to discover that it has a bug that wipes out all data. That's what tests are supposed to find. And you should not have test/staging data in the production system. It is good practice to dump the data out of production and load it into another environment for periodic testing with real-world data.
You should have a test database (not shared with production). It's a good idea to wipe out the data before every test.
You can have smoke tests that run in production. They will pretend to be a user(agent) and visit many pages, maybe even create things (with a special tag so you can find them again and delete them.)
I'd rather think of different database user with own data set. Database schema should be the same. I'd never run tests on production database with the same database user. Test logic shouldn't even be delivered to the client as it may lead to severe security issues.
In my opinion you'd need a full production-like data set for testing purposes, to be able to test every single feature of your application. And also you would need an empty database (without any bussiness data) for application clients to have it as initial point on delivery. Such a dataset shouldn't be tested as there is no data needed to test bussiness logic.
We are deploying an update to our main application in production. The update has been tested in QA and it looks good to go. Our client wants to do a test in production. For that case, we will run the application using "test data" in production and once the test has been finished, we will delete the "test data".
A couple of server admins are against this because "test data doesn't belong to production". I think it's OK since the QA server and the production server have different hardware and the databases house different applications (QA has more databases, production is dedicated). Besides that, are there other facts that I can use to back my opinion?
EDIT: adding context
The application is a tool that automates the reception and validation of data. We receive the files via email and this tool automatically validates them and imports them to the database. We have a BI system that creates reports using this information (excel files are received by email, then validate, then reports/views come out, all this automated).
The "test data" would be old files (good and bad files from previous efforts) that represent true data (actually it is true data but with problems or just too old).
Yes! But manual usage of test data in production does not sound like a good idea to me as it cannot be controlled or monitored. My answer below is assuming the test data is used for automated testing.
Test data in production is "todays" need. This was not a requirement back then when automated testing was not a requirement(or did not exist). So in general this will be frowned upon. Security is the main reason. Its impact in messing up site analytics is another reason. These are genuine and good reasons.
One cannot decide one day to simply put test data in production especially towards the end of project. This needs to be made a requirement from the time development starts. So the test data needs to be there in production from the very first deployment onwards. And its impact needs to studied and documented. Organization as a whole need to understand it's benefit and impact.
Test data needs to be divided based on it's type,need or context. eg: Retrievable test data and editable test data. First step would be to have Retrievable(read only-never changes) test data available. Perhaps this is farthest we could go in many case, still would provide good results. And creation of this read only test data needs to be automated and preferably documented.
The benefits of having test data in production is huge. An automated test of an application is more precious that then the application itself. If the management realizes that then at least the initial "frown" changes.I feel test data in production should be considered a requirement/userstory and all problems against it should be mitigated. And new patterns of development need to evolve in this area.
This discussion is also related to integration testing and this article focuses on the benefits of it over unit testing
Your admins are right. Having test data in production will expose you to the risks (security holes):
Test data in production can be used to do damage to your company (intentional or nonintentional).
For example if you have non excisting identities on production you can do payment to them. If they are linked to real bank accounts you lose money without the ability to detect it.
Test data can change your management reports. When having fake action, some can infuence reports and have impact on decisions made. This will very hard to track and even harder to correct.
Test data can interact with production data. If someone makes a mistake and make a wrong relation production data can be changed based on test data.
There is no good way of detecting you have test data, if you would mark it. All data can be marked as test data. If you handle the test data different in your businesslayer, it whould not be a real test of your production environent.
Nowadays it is a good practice have Staging environment with the same infrastructure configuration like Production, so you can execute pentests, load tests, and do whatever you want to do to ensure that Production will behave as you expect.