I got a project where I have to do some design customization and add few functionalities like workflows. I know we should not do these changes directly on production but to make a dev/ staging environment what is the exact way?
One way could be that we can create replica of this SharePoint online site and do changes there. After all changes are done and approve we can move them to production. But in this case also I would like to know how can we create a site's replica and then later sync it to main production site.
The recommended approach would be to create a dev/staging tenant and grant a subset of people access. So dev would be the devs, staging would be the devs and qa testers. Many companies that I've done work for don't want the extra expense so they opt to create separate site collections for dev and staging. Depending on what you're working on, that might be ok.
If you have an msdn subscription, you could spin up a dev tenant for yourself and separate it out that way.
Then to deploy, if you have everything scripted out, you can automate the deployments.
Related
I am in a SP Online environment where users do not have owner access to their sites. This makes life difficult in several areas, one of them being the promotion of apps to the app catalog. I am in a very large organization and we are looking for the cleanest way to allow devs to promote their apps to their individual sites. We also don't want to clutter the tenant app catalog.
I have been investigating site collection app catalogs. I am assuming that - once the ability for the site to have apps is enabled - that I would need to give a dev elevated access to the site in order to publish apps directly to the site?
The second question is around apps that might belong on multiple sites. If I went this route (publishing to local apps) would it then be incumbent on the devs to publish to multiple sites in their pipeline using CLI?
Thank you in advance!
I am a Solution Architect responsible for setting up a project's infrastructure on Azure. The project should be running in multiple environments (dev, staging, prod). As far as I learned the best practice regarding environment separation in Azure is to use Resource Groups. That's what I did.
However, this is where things start getting tricky. Our application will use Azure AD as OAuth Authorization Server. I want to have my AD isolated, like everything else in my infrastructure. I don't want to accidentally modify a production user from the dev environment and for the dev environment, I want to be able to create a ton of test users which I don't want to see in production. So, isolation.
The problem is I don't see any option on how to do this. My first instinct was to create multiple ADs. But when I do that, they actually need to create a completely new tenant for each of these environments. This seems really messy to me. Have to support as many (almost empty) tenants as I want to have environments.
Please, what is the right way how to do this?
Does Azure AD have some kind of support for isolation I require?
Am I missing something?
Note: this question was also asked in MS Q&A.
You're correct that a tenant is equivalent to a directory and a user is either in the directory or it's not. However, using RBAC, you can restrict the permissions on users so that they can't access particular services. It would be good if you separated permissions by subscription which is what a lot of major companies do and that's how they know which workload a subscription handles.
We are a small company and are still unsure how to start all this azure stuff.
Ok, we are clear on the technicalities like table storage and queues and all the that stuff, what we don't know about at all is how to set up the organization around developing for our developers. Which/how many azure accounts, shared or individual ones.
So far we've done classic windows development, so everyone has his environment, unit tests run either locally or on the build server (after pushing to mercurial or git), deployment from the build server.
The thing is that we want to use Azure not just as a hoster, but the full set, like blob/document/table storage, event hubs, storage queues, ReliableActors and everything. Things we can't do locally.
What's the appropriate way for azure then? There are about 20 to 30 developers and most have the enterprise msdn subscription.
What is a "company or organisation" account for? Should developers have their own accounts? Does DevOps need their passwords for all the bamboo or jenkins build stuff?
I went through this recently and I can share a few tips here since I'm also not aware of a DevOps specific platform to share this on StackExhange.
As far as organizing your subscriptions go look at Azure Pay-As-You-Go Dev/Test Subscriptions link
or Enterprise Dev/Test link if you are an Enterprise Agreement customer. These are aimed at development teams, you get discounted rates since you don't pay for software licenses that are already included in your MSDN subscription.
It is best to use individual developer subscriptions for exploration, POC etc while running your main dev workload in the Dev-Test subscription. It looks tempting to try and save a buck by spreading the work across multiple MSDN subscriptions to use the credits but I wouldn't recommend it. It becomes a pain to manage 20~30 subscriptions and they can run out of credits and things stop working. If you remove the spending limit on all the subscriptions you run the risk of racking up a huge bill accidently if multiple devs leave VMs on or add premium storage to VMs etc.
As far as DevOps go, use RBAC and Azure Active Directory to manage access and certificates for your DevOps tooling, build servers, release management etc don't use individual developer credentials for this.
And I agree with the other comments, get in touch with MS as well, this is just the tip of the iceberg but it will get you started.
My company process sensitive data and needs to restrict access to production environment. How do I organize subscriptons and (storage) accounts so that I have separate environments?
I could have completely distinct subscriptions but I want to give some devs the power to deploy on production while others should only have access to development assets.
In my ideal world, I'd add individuals to security groups. Whenever a thw dev wants to deploy on production, he/she would use his/her credentials plus an extra confirmation step, like an otp. This way I'd avoid mistakes but still keep simple users management. Is that possible in azure?
Eventually what you are wanting to do will be possible, and is possible to some degree depending on the resource. As more of the features of Azure make it into the preview portal (portal.azure.com) they are showing up with Role Based Access Controls, which is what you are looking for. Unfortunately, right now not all of the resources are there and some are there without full RBAC baked in (such as storage accounts).
For now, the best bet is to still separate by subscription. If you need developers to have the ability to perform a deployment you can create a script that performs the deployment (using stored PowerShell credentials or secured management certs) and then give the developers the ability to execute the script.
We started using Azure platform. Especially we are having issues in Web Sites platform. How we give different kinds of access to our development team.
Right now the development team could access the production deployment slots.
We need to be able specify the access to the system according to their roles in the organization.
Have your development team use their own subscription for development. That way, they never have access to your production environment. This is something I personally practice and recommend to customers.
This gives you the added benefit of also separating development and QA costs with your production deployment costs. In development, you may choose to use smaller and fewer instances (to control costs). Yet, in production, you may prefer larger and more instances (to meet demand). Having a separate subscription for each enables these options for you.
This is also an approach demonstrated in the Patterns and Practices Guide. It's a little dated and is in the context of Cloud Services (not Websites). But, the overarching principles still apply.
Microsoft has Role-Based Access Control in the roadmap for the new Azure portal but have not committed to any target dates.
If you're using Azure AD to manage Azure access there are some different roles available there.
Edit: Basic RBAC functionality was added to the new Azure Portal back in September.