Step 5 (Build, release, run) of 12FA makes it impossible for devs to change code at runtime. It doesn't explain why this is good.
It makes things like adding temporary logging, or applying a quick hotfix to production code - both very feasible if the application hasn't scaled beyond a single instance yet - impossible.
Is it recommended simply to prevent devs from shooting themselves in the foot (by deploying a change that breaks the running app), or is there some other benefit I'm not seeing?
Related
What is the best approach to use to make sure that previous versions of your mobile app don't crash when making changes to your backend database on a published app?
I've tried putting a check for database version on my app to show a need for updating the app if anything like that ever happens, but I'm not sure if this is the best approach.
I don't think I've ever experienced a forced update on any mobile apps out there... so I'm not sure!
Changing the schema completely isn't something you can afford when your old version of the app relies on.
If the cost of losing the old version isn't much, then you can just ignore them and ask them to update.
And if you can't afford to lose your old versions, you should add columns or even new tables for new versions and then handle the data validation on your codes and also separate the API versions so both old and new versions can get the right data.
You usually have to keep going with this approach until the cost of losing an old version is low enough to end the support with it.
It's really hard to get everything right on the first attempt especially for large scale apps even if you are experienced. You will get to the point that you have to make changes to be able to scale.
I need to put together a nice interface/UX that will run fullscreen as the primary shell/UI on purpose-configured hardware.
HTML5/CSS/JS will be the absolute easiest design path; I don't have anything that requires rock-solid 60fps framerates or similar high-performance requirements, so the live-reloadable nature of HTML easily makes it a winner for rapid development. (Plus, I'm using Linux, so I know my next (real) alternative is Qt, perhaps with Python. That won't be as fast to iterate with.)
Since this is going to be an embedded/appliance type setup, I don't need the "one-click run" packaged nature of Electron; indeed, I will far prefer the more traditional approach of a local application-/web server running in the background.
So, all I need is a basic headless browser to appear fullscreen for the duration the machine is turned on.
That could be Chrome, but here's the thing. The general Internet will be accessible from the devices in question, but only my own backend processes will use it. I'd prefer the renderer(s) not access the network directly.
I understand Chrom{e,ium} contacts Google for telemetry and metrics tracking, as well as to fetch safebrowsing lists and so forth - and that this behavior cannot be turned off, to ensure that some majority of web users don't end up with what are (in the context of "the whole internet") arguably-insane security defaults.
But for my use case, this behavior is pointless, because I'll only ever be accessing 127.0.0.1. There's no point for me to waste my bandwidth on this I/O; the effort being made to update this data in the background is effectively wasted.
I'm currently wondering what renderer solution to deploy, and weighing up NW.js, QtWebEngine and Electron (in that order). I particularly like the following from http://wiki.qt.io/QtWebEngine:
Auxiliary services that talk to Google platforms are stripped out
If I knew NW.js did the same thing, it would be a shoo-in and my choice would be made, but I'm not sure where to look.
Is it a good idea to make the effort to build a simple QtWebEngine kiosk shell, is NW.js resource efficient, or is there another option I haven't thought of?
I've tried CEF in the past; it seems somewhat clunky, or at least the demo shell does (I'm not up to recompiling it). Perhaps it's exactly what I'm looking for and don't realize?
I am just getting started with doing moderate web development work in Salesforce for my company, and I'm looking for some feedback/insight into the deployment process. Right now it's looking like we will be doing a fair amount of custom work using visual force and apex. What I am wondering is if I screw something up in my production org (data or metadata) is there a way to roll back to a snapshot or previously released version of my org that still works? With the mediocre development tools I am worried that when bugs do arise that I won't have a good fast way of addressing the situation.
I was reading about different ways to set up source control here:
How can multiple developers efficiently work on one force.com application?
But I haven't found anyone walking through the process of essentially reverting a change set or changing branches. Are the protections built into salesforce good enough that I just won't have to worry about bugs in production? Should I just not worry about having to revert a change set?
One of the ways this is handled is through the proper use of sandbox orgs associated with your production org. You can always keep a sandbox org that has the "blessed" instances of everything while you use another sandbox org to do major development destined for deployment to production. In the event that something seriously wrong occurs between the new development in your dev sandbox being deployed to production, you can roll-forward from your blessed sandbox to revert to what was completely working previously.
That being said, you're on to something when you ask about not worrying about bugs in production. Not that they won't happen, because they will, but rather that you'll soon begin to get a different sense for what broken means. A change set is only one way to get changes from one org to another, and a rather recent development on the platform. They have some limitations like not moving custom setting data, but generally work really well.
But it's true that when you've got good unit tests in place, coupled with all of the rest of the imposed referential integrity checks, it's really not that common to "break the build" so to speak, and wish to revert to some global snapshot of everything at a different point in time. More frequently, in my experience, you will revert isolated units back to previous versions and can do this with sandboxes or source control by pushing an earlier version forward until a fix is found.
Adam
I've been researching an app on the app exchange that at least looks like it will give me what I want. The product is Snapshot by Dreamfactory. Interestingly the sales people I talked to at Dreamfactory told me that salesforce uses their app internally to manage changes. I find it kind of unfortunate that this capability isn't included with my license but... here are the specifics of what I found that will be helpful for my specific question:
The ability to take a snapshot of your orgs meta data and copy or deploy it to another org. This will allow me to deploy/rollback changes.
The ability to diff 2 different snap shots (from different orgs) and see the details of what changed. This will help me to track down the cause of problems when they do arise.
I've been working on a drupal site. During the course of editing it i've added data, removed fields, made new fields, removed data, and added more data. Now the site is almost ready to go- but I feel like the database is very messy (with revisions to fields, etc)
How can I best clean-up my site before the official roll out? Also, what are good practices to use while adding/deleting fields so I dont run into this?
This is a workflow related problem. user491844 mentioned the usage of Features and #luksak told it's not a real answer, but I would like to explain why the usage of Features would be actually one kind of a solution to this.
Normally we do multi-stage development, meaning that you should have a separate environment for development and for production (at least; often a third area called staging is used for acceptance tests etc.: development → staging → production). This means you should try new things on the development environment and whenever satisfied with the result, move it one level upwards. This can be done in multiple ways, one possible answer is Features. In general, you should take a look on how code-drive development can be done.
It's very easy to see why this approach would actually solve your problem: in production, you wouldn't have to clean up things often, because it wouldn't have any extra cruft that a sandbox often has. It also adds a layer of protection: if you break the sandbox, you can just clone the production site and you're good to go. Using Features with added version control (probably Git) also provide a fine way to keep things in a safe place, allows documenting what's happening and makes re-using the different segments of your site possible - which is going to be a very good thing later if you're building multiple sites.
If you have a complete site, it's possible to "Featurize" it, but you will have to be very careful on how you build up the features. In general, try to build small features which only contain components related to a given functionality. You will end up with a lot of small features this way, but it makes handling dependencies easier. You can find a lot of articles on how to split up your features properly: like this and this. Good organization is essential.
One thing I would also mention: in production, you will probably want to keep the site as lean as possible, so setting up caching, disabling development stuff and UI components of some modules etc. might be useful. You can find several useful modules which can help you in production, one of those is Production check.
There are a lot of articles on this "how to move to production" topic that you should research to see the recommended steps, see this for an example.
So here is our problem:
We have a small team of developers with their own ways of doing things-- I am trying to formalize a process in which we are required to promote our code in the following order:
Local sandbox > Dev > UAT > Staging > Live
Developers develop/test as they go on their own sandbox, Dev is its own box that we would use for continuous integration, UAT is another site in IIS on the dev box, which uses our dev database. We then promote to staging, which is a site in IIS on the Live box and using live data (just like the live, hence staging). Then, finally, we promote to live.
Here are a few of my questions:
1.) Does this seem to be best practice? If not, what needs to be done differently?
2.) How do I enforce the rules to the developers? Often developers skip steps in order to save time... this should not be tolerated and would be great if it could be physically enforced.
3.) How do I enforce these rules to the business group? The business group just wants to get features out FAST. Do we promote only on certain days?
sounds like a good setup to me ... we don't have as may areas where I work. We have DEV > QA > Production.
1) I'm not exactly sure what "best practice" is, but your setup seems like a very good practice to me. My only concern would be in the Sandbox environment. Are there assurances that the developer's code is backed up daily? just in case their machine crashes hard? I'd hate to lose good dev code.
2) We have a "release coordinator" here who enforces access to Sourcesafe and TFS and also controls access to the QA environment so there are only certain times when they are available.
3) The same goes for the business testers except their authority comes through the Project Managers. The PM's have a document that gets filled out per project and testing teams are specified.
We do only promote on certain days (every other Thursday). However we do understand that there can be emergencies and we have done production releases on off days when the need calls for it, but those emergencies are documented after the fact and analyzed to see what went wrong and where we can make improvements.
I'd say as long as your environment is controlled and documented you should be fine. It would be good to make sure everything is backed up in the sandbox area and that a small group of people control the access to the other environments. I would also recommend you keep good documentation on the comings and goings of the "secured" environments, just in case something goes wrong you can backtrack through the logs and see what might have happened or who might have done it, not necessarily to point fingers but to go back and say "what exactly did you upload/change?" so we can see what might have caused the issue.
Best of luck to you,
Scott already answered pretty well, so i won't repeat his logic. The one he seems to have missed was:
How do I enforce these rules to the business group?
The problem is, you can not enforce anything on the business group. Only their managers can.
What you (as IT) can do is meet with the business side managers, and lay out the cost/benefit analysis.
Worst case bug
Likelyhood of that bug without proper process
Cost to the company of such bug.
Ideally, the bug would be something which actually happened in the past instead of a theoretical thing :)
Then compare that with the relatively insignificant (just make some estimates, hopefully with business user's input) cost of having proper process and associated slowdowns.
Basically, you need their buy-in, to convince them it's in their interest to not cut corners.
We have a similar setup at my shop. We enforce this by using different physical machines and who has access via passwords, etc. I develop locally on my own VPC, then check the code in. That is the end of it as far as I am concerned. Another person has access to the dev box where he runs builds as needed, he does not have access to the "live" box, another person does. This person has access to both the "dev" box and the "live" boxes--this way he can do an emercency deploy etc. if needed. Once a build has gone to dev and been tested, then, and only then, is a "live" build done.