Salesforce development and security review lifecycle

Question

I'm a bit confused about the number of orgs needed (and their purpose) for a development and security review process for a managed package.

• Do I need separate orgs for development and packaging?
• Do the orgs need to remain the same through out the life cycle of the app? Or can they be changed after the security review?
• What orgs do you need for applying for security review?
• What is the process for development for different org types and releases?

Edit: Added a few more questions:

Acc to the new salesforce security review test doc,

"Starting March 1, 2017 full Locker Compliance will be mandatory to submit for the security review. Therefore, the Developer Edition test environment provided for the security review must have Locker Service enabled. Enterprise edition and sandbox orgs will not be acceptable test environments starting March 1, 2017 "

"The review team recommends creating a free developer account because accounts do not expire and are provided at no cost. These will be the only acceptable test environments starting March 1, 2017. Keep in mind that the review team does not need or want direct access to the org where you have developed or packaged your application. The test org should be a separate dedicated org. "

Based on the above,

• Which are the acceptable test environments?
• Do we need to provide access to the packaging org for review? What does this statement mean - "Keep in mind that the review team does not need or want direct access to the org where you have developed or packaged your application."

I understand the questions are a bit disconnected, I'm new to the salesforce development and am in process of preparing an app for the security review. Getting a bit overwhelmed with all the steps needed. Can someone give a rundown of their development environment and process?

Answer 1

Do I need separate orgs for development and packaging?

No, but it is strongly recommended. For today, ISVs use unmanaged Development Edition orgs. In DX, you'll be using throw-away orgs for development, and a primary packaging org to distribute your app. You need one packaging org per managed package.

Do the orgs need to remain the same through out the life cycle of the app? Or can they be changed after the security review?

Your packaging org will always remain the same for all time. Your development orgs are not relevant for your security review. For the security review, you'll need a testing org must remain unmodified until the review is complete, including pushing new versions. If you do so, it will not invalidate your security review, but it will delay your security review.

What orgs do you need for applying for security review?

Your packaging org and a demo org with your package installed. This is outlined in the security review process once you apply.

What is the process for development for different org types and releases?

You only package in a single primary org. In the current ISV cycle, you use ISV Developer Orgs, and use migration tools to move code and metadata into the managed package. In the near future, you'll use DX scratch orgs to do your development. In DX, you can build Professional Edition and Enterprise Edition Developer Orgs so you can develop in either environment, as well as test how your code works in each edition.

Answer 2

Ok. To develop a managed package you need one org and one org only. It must be a developer edition in wich you will do all your developments.

You can use other orgs to develop parts of your project, but there's no easy way to deploy between orgs.

You cannot change org after security review. In fact, you developer edition will be the same for the whole life of your package. You can later create new versions of you package (2.0, 3.0 and so on) but you'll continue to use the same org.