So how are you managing your Windchill code?

[avillanueva]

Curious about best practices and how others manage their Windchill code. Always looking for better ways and tips. Obviously this depends upon the OS you use for your servers and your chosen IDE.  Let me start. I've taken different approaches over the years but since I mainly a single developer, its been ok. The occasional intern does present config management challenges. 

IDE: Eclipse

Windchill OS: Redhat Linux

Source Control: GIT/Bitbucket/Jira

Environments: Test/Prod but looking to build out Dev with next upgrade (long story).

Process: Code changes against Jira issues. Compile in IDE and copy to Linux side to Test Env. Execute Jira test scripts. Once tests pass, push code changes into Bitbucket tied to Jira ticket. Plan downtime to move code changes to Production. Process to move code to Prod is same (copy from landing place where I posted last Test server copy). Yes, I am using wtSafeArea and ant scripts to push into codebases.

Any suggestion? Share your process?

[Ajit_Kulkarni]

Hi,

I really appreciate that you have started this thread. 

We have four environments DEV/TEST/QA/PRD. For each environment we have parallel GIT repository. Rehost is very common to make sure it will work on prod.

I follow the Windchill folder structure for code management.

• src : for all source code changes
• wtsafearea : new and changed windchill files like jsp
• wtCustom : custom states 
• load files : everything custom that can be loaded , through load from files or manually through UI
• other parallel Windchill folder structure which deploy customization doesn't support e.g. conf/wvs.agent.ini

Deployment is simple. Copy all the changes from GIT and deploy to Windchill. We use ant to deploy majority of the stuffs. 

Process is like this.

DEV : Almost a nice play ground for developers. Multiple GIT repository check-in. After all development we finally rehost DEV again and verify code and deployment works. 

TEST : Manual copy of code from DEV to TEST. Rehost TEST and deploy the code. Verify all the functionalities and check for regression. 

All the issues found needs to be fixed on DEV first and then we move to TEST. 

QA : Once we have go -ahead on TEST. Manual copy of code from TEST to QA. Rehost deploy the code. Again verify all functionalities.

This is final check point before prd. Go no go decision happens here. 

PRD : Same Manual code copy from OQ. Take production down. Take necessary backups.

Deploy customization. Verification. Go live or rollback. 

Sorry for long reply. Hope you find this helpful. 

Regards

Ajit 

[avillanueva]

Curious about your GIT integration. It seems like your Dev environments have Windchill loaded. How much of that do you manage in GIT? Is it just source or are you managing compiled classes to? Here is an example of mine. I've tried to be religious about linking Jira issues to commits in BitBucket. I think I need to amend my steps to pull from repository not from local compiled classes in Eclipse. I can see potential for error here or at least create a separate build environment. Just might be too much overhead for my small operation. 

[HelesicPetr]

Hi @avillanueva 

I use SVN.

In my case I have different folder structure which follows customers then Windchill structure.  

In SVN I keep just java source.

I only keep Classes in a package committed in SVN which are deployed on production server. 

PetrH

[avillanueva]

I've had some time to think about this and plan some changes as I go to Windchill 12. I have my DEV server up and running but hearing some differing advice. I certainly will have a master branch which will include only things ready for Production. Development branch exists and I will create feature/bug branches for each Jira task modification, folding back into Development when done.  

Two things I have heard don't make a lot of sense in the way we I with Windchill development:

• Store all PTC codebase and Jars (whole darn thing) in your source control system. My customizations vs PTC is 1:1000 in terms of size. I see it easier to only managed custom or modified files in Bitbucket. Yes, CPS updates do occur but those are rare enough the be unique events and can be managed by updating libraries sourced by Eclipse. 
• Do not store .class files or compiled code into Bitbucket. I get this that you can generate the classes from the .java source code but this will require creating a build environment and process on DEV/TEST/PROD to move code in. Since Eclipse compiles on save, is there is risk to not rebuilding in each server environment? It would also make porting code to each environment easier since I could clone the branch to the server and copy out the compiled classes.

Let me know if you agree/disagree.  I can see if you are developer handling multiple clients and version why some of above might be a good idea. Am I using the wrong side of the hammer?

[AndyHermanson]

Have you utilized the wtSafeArea and wtCustom folders? There you should only need to track the files that are modified and deploy them to your system. 

Search (ptc.com) - wtSafeArea

[avillanueva]

Always do, who doesn't? Just trying to minimize hops and file copies moving code from one place to another. This would be the final location for compiled code. However, way over in my eclipse project on my laptop, source code is under src/ and classes get built to bin/ with corresponding subfolders. In the last revision, classes were SCP'd over to wtSafeArea/siteMod ... and ant script to push into codebase.  Many steps. 

At least now, I can standardize pushing code to each env but creating a git clone and checkout the development or right branch.  Discussed pro/cons of taking compiled class files from Eclipse and also storing them in bitbucket so I can pull down with same checkout.  There is a competing method of rebuilding against current environment after checkout (recompile class files) but I find that extra work to eliminate an issue I might never have. 

[AndyHermanson]

At my last company we used Azure Devop (could use Gitlab or Github, etc). We also had the main branch 'master' that was Production and a branch for each test environment. Pipelines allowed us to do the build and place and then call we used scripts to automate the Windchill commands like ANT and other shell commands to deploy our files and reboot the services. 

[HelesicPetr]

Hi @avillanueva 

I'm also curious :D.

IDE: IntelliJ Idea

OS: Windows

Source Control: just SVN

Environments: Develop/Test/Production

I have more customers so I need to keep one project for one main Windchill version with right version of Java and wch library. 

For each customer I keep one module with source code. Also I have one module to share methods which are used everywhere.

Deployment depend on Customers restrictions. Sometimes it is complicated because the process is fully manual work. copy files/ update properties/ configs atc.

In another cases there is a full automatization with scripts that they do everything for you in one doubleclick. 

I guess that interesting information is that my IDE is installed on computer without Windchill installation. I use only libraries from specific Windchill versions.

in other hand if I need to create new object soft types in Windchill I use the Eclipse as described in development manual or help.

There is some procedure to generate SQL scripts to create correct tables in Windchill database which I was not able to reproduce with IntelliJIdea.

PetrH

[avillanueva]

Same here as for developing on system without Windchill installed. I just had to make sure the codebase and library jars were copied across. Yes, looks like moving files to higher environments is the same all around. I only have 200+ modified files so its not hard to keep track of them. Just need to ensure that you keep timestamps the same when moving so its easier to see that files are identical. It does seem like extra work where I post to my home area (mirror of wtSafeArea) then copy to Windchill's wtSafeArea. I guess I can learn ant better and write some scripts to shuffle files.