Bitbucket and Pycharm setup

Pipelines
, ,
#1

I am a Maya generalist that has been moving sideways into the Technical artist and Pipeline TD role at a small animation/interactive studio (<10 animators). I am embarking on the adventure of starting to use version control (finally) and the brave new world of Git. In parallel with our Unity developers, we’re evaluating Bitbucket Cloud to host repositories, and using SourceTree to manage the version control. I have been scripting in python with PyCharm, and am wondering about the best way to work, in short.

  1. I would prefer to use SourceTree to really manage the version control stuff, since the interactive team is using it too. Should I then just ignore all the VC features of PyCharm, or is there a recommended way to have them work together?

I am trying to anticipate what a git branch structure might look like for the tools I’m developing, but it seems clear that I should do development and rigorous testing on a development branch before merging to the master branch for deployment. Currently users have a .mod file that points to a network scripts folder with a userSetup.py that creates a custom Maya menu populated with various tools. I have a bunch of questions about that, but for now:

  1. What’s the simplest way for me to test the development branch version of the tools, while normally having access to the deployed set of tools, but making sure I’m not running one when I think I’m running the other?

I’m at the point of just trying to figure out the right questions to ask, so I’ll leave it there for now, and I appreciate any insight into “best practices” or at least “this works for me”.

1 Like
#2

Hey Stwert,

I’ve been developing the DevOps side of our Pipeline team over the past year and it’s been quite a journey.

One article which helped me along the way:

I would highly recommend spending the time to work out how you’re going to structure your pipeline code and plugin control early on.

One of the things which has benefited us greatly has been an isolated source location for code currently being developed by each member of the pipeline. We make use of a system environment variable in a lot of our code to determine which root path to the code base we want to use. We then wrote a tool to handle toggling that environment variable path to a development path.

The result of some of my more recent research has indicated that using a specified branch for deployment of ‘BETA’ or ‘production ready’ code could be very useful.

  • Read as much information as you can; the more you know, the more you’ll be able to find a practical application of Git which will suit your needs. The system is quite flexible and I’m sure it can be tailored to suit your unique needs.
  • Make some heavy use of commit / push / pull hooks to automate a number of more complex deployment processes.
  • Keep your repositories as streamlined as possible.
  • There are strengths and weaknesses in breaking up the pipeline into submodules. - Still on the fence about whether they’re a good investment of time and energy. - We use them and it’s helpful in some cases, but becomes frustrating at times.
  • Make heavy use of git configs. (If using submodules, you can ignore submodule versioning to prevent ‘modified’ status on a parent module when a submodule commits.)

Resources:

We use PyCharm’s built-in pull / commit / push workflow when dealing with the repositories and haven’t had to do much external GUI control or management. If I need to do something specific I’ll just jump into the Git Bash and do it by hand.

Hope that helps!
Please feel free to ask any / all more specific questions on the topic as I could use more people to bounce ideas off of as well.

Cheers,
Maj. Dave

#3

Thank you for the information and advice Dave, I appreciate it. I do acknowledge that figuring out the structure ahead of time can save a lot of headaches. Unfortunately I don’t feel I know enough about the ins and outs of Git systems to really anticipate what my workflow will be. That being said, I will look through your recommended resources and try to learn as much as I can before committing (no pun intended) to a specific strategy.
Thanks again.
Stuart