1 2 Previous Next 18 Replies Latest reply on Jun 26, 2014 7:35 PM by Bill Robinson

    package and promote to production

    Raja Mohan

      hi, I have a set of scripts, blpackage, vgp etc on a folder under depot. Set of corresponding jobs on a folder under jobs. There are also component templates and other parameter everything makes a build process. How can i package them together as a deployment and promote to production environment with ease? I dont find export on the folder level. Any insight you can provide will be helpful, I am also interested in knowing how others promote development, staging and production?    

        • 1. Re: package and promote to production
          Joe Piotrowski

          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.

          • 2. Re: package and promote to production
            Bill Robinson

            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 ?

            • 3. Re: package and promote to production
              Raja Mohan

              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?    

              • 4. Re: package and promote to production
                Yanick Girouard

                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...

                1 of 1 people found this helpful
                • 5. Re: package and promote to production
                  Bill Robinson

                  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.

                  • 6. Re: package and promote to production
                    Raja Mohan

                    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.

                    • 7. Re: package and promote to production
                      Bill Robinson

                      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.

                      1 of 1 people found this helpful
                      • 8. Re: package and promote to production
                        Raja Mohan

                        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.

                        • 9. Re: package and promote to production
                          Yanick Girouard

                          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 !

                          • 10. Re: package and promote to production
                            Bill Robinson

                            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.

                            • 11. Re: package and promote to production
                              Bill Robinson

                              but devops!!!


                              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.

                              • 12. Re: package and promote to production
                                Raja Mohan

                                :-) guess that will be the story on other side.

                                • 13. Re: package and promote to production
                                  Raja Mohan

                                  agree on the well defined process. Our goal is to get there, will cross hurdles as we comes across.

                                  • 14. Re: package and promote to production
                                    Bill Robinson

                                    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 ☺

                                    1 2 Previous Next