Development and Deployment Procedures

Pho3nix

Pho3nix

The Legend
Joined
Jul 31, 2009
Messages
32,826
Reaction score
3,033
Location
On the toilet
Hi all,

As per this thread : http://mybroadband.co.za/vb/showthr...-to-track-Stored-Procedure-Changes-or-Options

Thought this would be a safe haven to speak about what procedures (source control, deployment etc. ) your dev house or Mom&Pop shop use for their development.
It shouldn't have to be mentioned but please no personal insults :p. We aren't arguing about how long .net will remain relevant here :p

Your input would be appreciated.
 
We tried a few such as Octopus, but in the end we landed up writing our own. So our tool chain compiles all our projects, runs all our tests, creates our zip files, informs the servers of incoming packages they then get downloaded, then the server component unzips them, checks service signatures, checks to see if previous versions exist, if so they are then polled to see if they are allowed to shutdown (might be doing payment transactions), if they are they are uninstalled, backedup, new versions are then released, installed, started, a quick test is run to ensure an end to end success (just a basic procedure for each service to test its various functionality). This is all viewable via a web interface to see the progress or any potential issues.
 
TBH, this is a massively complicated concept...

We found that web deployments and service deployments are the easy thing to manage. DB Deployments on the other hand, they're a nightmare. Dependency checking ends up being the biggest thing to be managed rather than the actual code of the deployment.
 
ToxicBunny said:
TBH, this is a massively complicated concept...

We found that web deployments and service deployments are the easy thing to manage. DB Deployments on the other hand, they're a nightmare. Dependency checking ends up being the biggest thing to be managed rather than the actual code of the deployment.
Click to expand...

Our DB deployment is the easiest task :) We have an app that syncs our domain structures and inserts new static data if there is any. We do not use views or sprocs at all.
 
semaphore said:
Our DB deployment is the easiest task :) We have an app that syncs our domain structures and inserts new static data if there is any. We do not use views or sprocs at all.
Click to expand...

Then you are lucky :).....

Too many views, and sprocs, and tables.. and they get changed OFTEN..
 
semaphore said:
Its a VERY big system :P
Click to expand...

I would say 2500 tables is a decent sized system... I don't even WANT to know how many tables in our system.... I actually dont' think anyone has counted because we would all pass out with fright.
 
ToxicBunny said:
I would say 2500 tables is a decent sized system... I don't even WANT to know how many tables in our system.... I actually dont' think anyone has counted because we would all pass out with fright.
Click to expand...

Yeah we got to the point where we thought should we really add more, but we needed them. Our workflow engine itself is few hundred tables.
 
semaphore said:
We tried a few such as Octopus, but in the end we landed up writing our own. So our tool chain compiles all our projects, runs all our tests, creates our zip files, informs the servers of incoming packages they then get downloaded, then the server component unzips them, checks service signatures, checks to see if previous versions exist, if so they are then polled to see if they are allowed to shutdown (might be doing payment transactions), if they are they are uninstalled, backedup, new versions are then released, installed, started, a quick test is run to ensure an end to end success (just a basic procedure for each service to test its various functionality). This is all viewable via a web interface to see the progress or any potential issues.
Click to expand...

That's freaking awesome :eek:
 
We also find the db change deployment as well as management to be our most difficult to handle. Limiting access to live environments without hobbling the devs, putting tools in place to manage these things, all takes time and resources to create and implement, all the while we have more than enough non-internal development to deal with :p
 
ToxicBunny said:
Then you are lucky :).....

Too many views, and sprocs, and tables.. and they get changed OFTEN..
Click to expand...

Its actually very easy to manage. In fact the DB side is the easiest. We use many stored procedures or packages as Oracle calls them.

We have a web based source control system that versions everything and packages up a release which can consist of database packages, DDL statements to create, alter etc, scripts to run DML, compile and deploy front end files to the application server. We can manage C programs, Unix shell scripts.

This allows us to package up DB, Oracle forms source files, C programs, java, and Unix scripts as a single package that can be released to any DEV, UAT environment, tested, regression tested etc. The system also consists of a user acceptance sign off and approval to ensure only tested and signed off updates are released to production servers. Provides audit trails so that we can see exactly which version of a module was released, when it was released, when it was tested, when it was signed off and by who. The package contains the project references as includes the project documentation(which is also saved in the source control).

The software was commissioned from a Danish IT company ages ago and we have customised it over the years.

The hard part is the finicky java classpaths. I hate java :)
 
Last edited:
Git/Stash that kick off Jenkins builds when pushing to the dev branch. Jenkins executes bat files that build, test, package, upload/download from Nexus and deploy. On some builds I use psexec to remotely install windows services. Psexec is crazy dangerous though :p

So if all goes well your commit will end up being tested and deployed to your environment without any human interaction. Releasing to PROD is still very manual....but we'll fix that eventually.
 
Last edited:
zippy said:
Its actually very easy to manage. In fact the DB side is the easiest. We use many stored procedures or packages as Oracle calls them.

We have a web based source control system that versions everything and packages up a release which can consist of database packages, DDL statements to create, alter etc, scripts to run DML, compile and deploy front end files to the application server. We can manage C programs, Unix shell scripts.

This allows us to package up DB, Oracle forms source files, C programs, java, and Unix scripts as a single package that can be released to any DEV, UAT environment, tested, regression tested etc. The system also consists of a user acceptance sign off and approval to ensure only tested and signed off updates are released to production servers. Provides audit trails so that we can see exactly which version of a module was released, when it was released, when it was tested, when it was signed off and by who. The package contains the project references as includes the project documentation(which is also saved in the source control).

The software was commissioned from a Danish IT company ages ago and we have customised it over the years.

The hard part is the finicky java classpaths. I hate java :)
Click to expand...

If you're running a single production system.. and it's all a single product as it were then yes it's relatively straight forward :)
 
ToxicBunny said:
If you're running a single production system.. and it's all a single product as it were then yes it's relatively straight forward :)
Click to expand...

We have more than 1. About 7 that I know of. 3 of which I am involved in at some level. The system is scalable. Environments are flagged as either DEV, UAT, UATR(pre release regression tests), MIRR(mirrors), or PROD

Packages can be pointed to any environment. Depending on what category the environment is, only certain users can release into them.
An environment consists of multiple servers. A typical environment consists of an Oracle database on Unix, Oracle Appliction Server on Unix. Internet on Windows Server, A another Oracle database on Unix for the web. Our DEV and UAT environments are hosted on a single box. We have about 50 Dev and 80 UAT environments on the 1 Unix box. Production environments are slightly different as are the mirrors. Not sure about the architecture. Our Dev teams aren't allowed to fiddle on them :) We have a dedicated App Support team for that.
A package will seldom require release of modules to all the environment members, but every now and then there is such a project. Typically we release changed to the Oracle DB and App server. Changed to the web and its DB are usually done separately except in larger projects where there are dependencies.

The DB is not small either. Checked yesterday after seeing Semaphore's response. Have about 2379 tables and 1375 Oracle Package Bodies. An Oracle package is basically a grouping of functions and procedures.
 
Last edited:
A couple if years back I worked in London on the UK Dept of Works and Pensions systems. As Devs we never ever saw the production systems at all. Never saw the data. No access to mirrors. No access to live data whatsoever.

This system is a real global test environment. The dev and test servers where located in Chigaco, U.S. and we had backup servers in Frankfurt. Yes fail over for Dev. Development and UAT was basically 24hrs with handover between Mumbai, India and Newcastle and London UK, occurring daily.
Deployment of new code release and test data build could be scheduled. UK and India teams would schedule their builds do that they where ready for the other team first thing in morning.
This was a complex system. It interfaced with HMRC (tax authorities) and with pensions.
These things aren't difficult to do. What is difficult is changing human behaviour to devs to stay away from production environment. That requires strong management. When I read about the problems guys have with this, then it's because they have weak managers. And probably don't have the neccessary skills because they either think they know IT all(the most dangerous people in IT), or simply just out of their depth.
 
Been working with Git lately. What a terrible, fiddly experience. So much less user friendly than something like Subversion or CVS.
 
It must be a familiarity thing then, I went from subversion to git and there was a bit of a learning curve but now I wouldn't give it up
 
Kilgore_Trout_Redux said:
Been working with Git lately. What a terrible, fiddly experience. So much less user friendly than something like Subversion or CVS.
Click to expand...

It's like anything you're unfamiliar with :) They all have their strengths and weaknesses. Currently I'm using IntelliJ, Maven, Sonar and GIT for development and then Jenkins for deployment.
 
You must log in or register to reply here.
Back
Top
Sign up to the MyBroadband newsletter
X