Creating contexts in the studio is described in the recipe Adding contexts to a context group in Chapter 6, Managing Context Variables.
Pros
This is the simplest method of managing contexts. It all takes place in the Studio and is very visible to the developer.
It is also is a reasonably good way of protecting an environment, because when the code has been deployed, the context variables and launchers in production are usually available only to operational personnel. This means that the values available to a job in production, for example, passwords, can only be set in production by operation staff and will never be known by other personnel.
Cons
The number of contexts can easily get out of hand and become unmanageable, especially when multiple developers are working on the same project. Each will usually require a copy of the context, uniquely named, containing their information for their test environment.
Another downside is that it is very easy to create different context groups with different contexts, so that you end up with a variety of flavors or development, for instance, dev, DEV, Dev, and so on.
However, great care must be taken when using this method to ensure that after the first deployment of the context variables and launchers in production, they are not accidentally copied over when deploying a new version, or that the support staff remembers to update them if the new version of the code is copied to different folder.
Conclusion
If the processes surrounding this method are robust, then this can be a reasonable method for deployment in a small environment.
