After building / deploying a successful release deployment system as an STP web app using SVN, following the excellent design principles here, I have now been tasked with re-wiring everything into TFS.
We have TFS 2013 (so, seperate RM client), SAS 9.3 and four Windows SAS environments (DEV, TEST1,TEST2, LIVE). Most of our work is DI ETL, scheduled in LSF.
Whilst I know there IS a project that allows GIT merging of SPK files in 9.3, it is subject to certain restrictions that are not palatable for us. Therefore (like 99% of us) our branching strategy is basically.. no branching. And we will have the following source control folder structure:
ENVIRONMENT
- BASELINE
- /SASApp (everything under Lev1/SASApp, minus logs etc)
- /ROOT.war (css, js, images, html etc)
- (various other folders in source control)
- RELEASES
- /Release XXX (subfolders containing release artefacts)
Developers will have a web front end so they can create a new 'package' (creating a new releases subfolder), and then use a 'picker' to select metadata (jobs, tables, flows) and physical (.sas, .js, .html) files for inclusion in the package. They will also provide any manual deployment instructions.
All developers work (check in metadata, update .sas files) in the DEV environment. When they are ready to deploy (to TEST1) they will select the appropriate 'build' in TFS. A custom build step will execute a powershell script, and I'm hoping it will be possible as part of this process to pass through some kind of release identifier. The powershell script will call an STP webapp, which will use a system account (sassrv equivalent) to look up the Release folder and perform an automated deployment of all the Release folder contents (.sas, .spk etc) into the target environment. It will take a backup first (so that the deployment can be undone), then import all the metadata, deploy the jobs, check in the physical files & capture the logs. Data Model updates are an example of a manual step (for now).
Presuming the build / tests are successful, the package folder contents can follow the same deployment route (via Release Manager) into TEST2, and then into LIVE (with appropriate signoffs in the Release Manager client tool).
My questions were... What are the pitfalls with this approach? Could it be done better? What tips / tools / techniques should I be aware of? Can anyone share experience / code / diagrams on this subject area?
Our whole IT department uses Visual Studio and TFS, and staying with SVN is no longer an option (despite the handy DI Studio plugin).
/Allan
SAS Challenges - SASensei
MacroCore library for app developers
SAS networking events (BeLux, Germany, UK&I)Data Workflows, Data Contracts, Data Lineage, Drag & drop excel EUCs to SAS 9 & Viya -
Data ControllerDevOps and AppDev on SAS 9 / Viya / Base SAS -
SASjs