Deployment of first solution on-premise

Yes, the code should work fine if it imports was successful of there were no issues in the code.
Ideally it is not advisable to create group in each environment as the uuid will be different.
Now, if you need to give security to the process model and migrate to another environment then you will face issues as the uuid is different for the groups.

@sudhak Absolutely there isn't a need to worry about dynamic groups. Just make sure that dynamic groups aren't included in the Export. These dynamic groups should be associated with the environment in which they are created and they should stay in the same environment for a lifetime or handled in the same environment for deletion/modification purposes as long as they are meant for handling environment specific objects such as process instances. Also, make sure that you are not carrying any development activities where the dynamically created groups aren't directly referred by any objects that you export across the environment. For instance, a dynamcially created group can be used in the security of process instance, or a record which queries the dynamically created group by checking the group id in database or a PV in a process but it shouldn't be directly referred in the security of the Process Model\\Record Type etc.

One thing we learned a little late (years ago) was to use your system account if possible. When you import new objects they are 'created by' the user that performs the import, since many of the security related functions and logic (a process calling a subprocess) depend on it running under the context of whomever created the object or process this keeps them consistent. Also, if each developer imports to production over time using their accounts not only can this cause issues with security (i.e. developer C has lower/higher rights in the future than when they imported) the code may either not work at all or give too many rights) but the accounts used to import can never be deactivated. If you deactivate the user the applications may loose their security context...so if you buy X licenses in Appian and 10 people over time import to Prod you essentially have used 10 accounts in perpetuity.

We now try and consistently import into our QA & Prod environments using a system account. In Windows, we hold the shift key and right click on Internet Explorer, select 'Run as different user' and then enter the credentials for the system account. Connect to Appian and (login again) import. Then, in theory at least, all objects when created are owned by that 1 account. Updates to existing objects generally don't have to be done this way, but we try to do so as a good practice since your import package likely has at least 1 new item in it. This also benefits because the system account then gets Alerts (at least in our environment) in addition the individuals that you configured in the process models.