I'm going to assert that there is no "with ease" option here. I'll let others chime in if they have experience doing this in different ways. But to my knowledge, this is all about what groups of people do you have, what functions do you expect them to perform, against what servers, and matching all those Roles and Permissions in BSA accordingly. I would also assert that having different directories that match your Roles and Permissions will be important as well.
What do you mean by ‘promotion’. Most promotion is simply an acl change. it sounds like you are trying to also export/import across different bsa envs ?
yes different environment. We have development and prduction areas, and I was even planning for a staging area. Is that not a normal practice? does everyone develop in one environment?
1 of 1 people found this helpful
You're basically doing it like we are. We also have multiple environments and don't promote simply by changing the ACL of objects, we export/import from one environment to another.
There's no easy "one click does it all" method unfortunately, and the method will depend on the type of objects you need to promote.
Sometimes you can simply export a batch job containing other jobs to automatically export the whole shebang in one go, but if some dependencies are not exportable you'll have to do them manually. For example, if you have added files manually to your file sever.
You must also be careful with Component templates, as if it already exists in your prod, you can't simply re-import it over it, you have to merge the template using a blcli command instead...
Well, a lot of people seem to do this…
To me this has always seemed like a confusion of purpose. if you have a system that is supposed to manage something from its entire lifecycle, why wouldn’t you do that in a single instance of a tool? I mean, do you check the application code into multiple rcs repositories – one for dev, one for stage, one for prod ? and if you are using bsa in 3 different environments, are you treating the blade in each env as production? Just because something is running in dev doesn’t mean it’s ‘dev’… for example, if your dev bsa dies because someone was testing out a config or patch to bsa itself, now you can’t deploy, and that’s a ‘production’ problem….
Yes – you need to segregate between the different environments, but that’s what RBAC is for.
Bill Robinson I beg to differ, how do you test the lifecycle of bsa product itself? how would you maintain and test the patches and promotions to the product? I understand from a logical perspective it is a tool that is going to manage the entire lifecycle of servers, but normally in production environments there are stricter change control rules we need to adhere to which will hinder development needs. Usually the build development team is not the same one that deploy and maintan builds, also they are not the BSA administrators themselves in production.
Looks like the product wasn't designed to use the way we are using and it was designed using BMC professional services. Don't have much history, but looks like i need to reconsider the way we do things. Another one to add to my list. Thanks for your insight though.
1 of 1 people found this helpful
Two different things here – pushing code from dev through prod using a tool, and then testing changes to the tool itself. So you have your ‘prod’ bsa that manages your various environments that you promote apps through, and then you have a test bsa env that is only used to test changes to your deployment framework and test product changes. it’s not used to actually promote code from one env to another for actual ‘production’ work (meaning any of the dev to test to prod phases)
Just because you have dev and prod users logging into the same instance of bsa or any other tool doesn’t mean one can touch the other’s stuff. we have I/A/MSP customers where their customers have access to a single instance of bsa, and never know that there are other users beyond their company and the host in the system. you can segregate the access so if you want dev to have certain access to the dev systems but not anything else, then fine. and they don’t even need to see prod or test. And prod users don’t need to see dev or test.
We have a lot of customers setup like this because they have erected walls and policies where you can’t have anything that touches dev also touch prod. that’s fine – those walls can still exist inside bsa by means of rbac.
If you are going to go between envs then you need to work out the export/import logic and how you will know what to export, and then where to import and then what to do after that.
I completely understand. I would have definitely taken in to consideration of the software framework and limitations in designing our environmnets differently if i had been part of it. That is one of the reason why I mentioned about adding to my list so the flow is smoother. That was just my rant about little disappointment professional services didn't scare us away from inhibiting ourselves when they implemented it. Now I am inheriting the environment and facing challenges.
It's from a security perspective. RBAC is one thing, but then there's the networking. The DEV in our case has dedicated targets that are not customer owned. If we screwup on them, it's our problem. If we'd use a common environment for both dev and prod, we'd risk executing a dev job against a prod target because the RBAC wasn't set right or it's a BLAdmin running the job and he has access to everything anyway. Our customers don't want to risk that. There's also the point of maintenance windows. Prod is supposed to be up almost 99% of the time, and we only have a single weekly maintenance window,. For dev, we often have to test new settings and restart the app servers. Having a single environment for this would mean we couldn't test much without affecting production users.
Most customers I know will do the same too, and always separate their test, dev, staging and prod environments on different physical servers/vlans to avoid potential security vulnerabilities and also make it easier for audits. To me it just doesn't make sense to have a single infrastructure for all environments. It's way too risky and too limiting !
It really depends on the env - in some cases customers have this big wall up between different envs and directives that say X shall not touch Y like yanick mentions below. if your point of access control is just accounts or ssh or whatever it would make sense to segregate. but it could be the having a single system that controls access w/ some kind of separation (eg, rbac) would be secure and the restrictions could be changed. i've been in those discussions before - usually it goes like
"you can have 1 bsa and rbac"
"we have a requirement to not touch dev/test/prod from the same place"
"ok, then have 3 bsa"
maybe w/ more pushing and education that could have gone another way, or not.
no - i understand - i think you can still have the segregation via the network and such, and that certainly makes sense. but i think if you have an access system that can accomplish the segregation, and keep the silos separate, it worth while to check into.
it's a trade off to some degree - what i would say as a perceived security issue vs the need to automate the export/import vs acls.
it's all do able - either export/import or acls.... you just need to have a well defined process.
:-) guess that will be the story on other side.
agree on the well defined process. Our goal is to get there, will cross hurdles as we comes across.
So what do you have now ? the separate envs and you need to automate the export/import ?
I’ve done both kinds of implementations before, I just prefer the single blade across all envs ☺