Here’s the team wearing their BRAND NEW Deployment Manager T-shirts!
We’ve got a few going spare, so who else wants to get their hands on one?
All you need to do is comment on this post letting us know what your biggest issue with deploying your software is, and we’ll get a T-shirt to you as fast as you can say ‘ingeniously simple deployment!’
Untested, last second entries into the deployment and a manually compared and difference scripted database method have “killed” us on deployments. Some of which have been over 6 hours, pressing into the wee hours of the morning.
Half of the business being 8-5 M-F, the other half being 24/7. Hard to find a maintenance window (outside of the set windows) for deployments for which everyone is happy.
I am looking forward to trying out your software!
Time and resources!!
Coordinating things between two dev teams on two different continents.
Syncing downtimes on three diferent time zones / three diferent continents! It is hard to determine what’s the best time to do deployment because “best time to have downtime” does not mean the same for all!
Users still insist on using IE8
Ensuring the code is in sync with the database !
Maintaining and tracking the Stored Procedures versions is a big challenge, as it keeps changing a lot during User Acceptance Testing.
Dependencies, dependencies – it always seems to be the trivial dependencies that hold things up!
Dependencies and environment-related config.
Getting management to understand the importance of proper software deployments!
It starts as “It must go today!”
And later “Oh, I forgot to tell you, it’s gonna be tomorrow, we are not ready…”
And sometimes, “We forgot to tell you, we’re going to pull xxx out so it can go tonight…”
And later, “Sorry, we should have told you earlier, it’s not working, but it has go tomorrow, no excuses this time…”
Repeat
Biggest problem is tracking the many different environments, each with many tiers and many machines and having a single source of truth as to what’s running on what.
If I were to pick just one it’s that it takes too long, involves too many people, isn’t self documenting, is more difficult to roll back, lacks accountibility, and is massively prone to human error.
Ok, that’s really more than one…
The lack of communication
Making deployment repeatable and easy to rollback if something goes wrong are main issues.
Managing branches of code. We’re done with 3.3, start working on 3.4.. wait, no! Add something to 3.3 before it’s out. Ok, now we can push 3.3 but don’t push those things that are half done for 3.4.. And make sure it’s all tested.
In house developed deployment tools that need constant tweaking
Thanks for the t-shirt guys – love it
/R
Do I have to pick just one? I could probably post enough to get a week’s worth of T-shirts.
* Pushing the right tag to the right environment without editing build configuration files.
* Deploying automatically via a timed trigger
* Pushing out database changes (schema and data alike) in conjunction with the code deployment.
* Updating security (database & application server filesystem) configuration in conjunction with the code deployment.
* Notifying interested parties of the deployment results, including detailed error logs in the case of failed deployments.
Deploying to production when business users are constantly adding to the production stored procedures, a nightmare of maintenance follows.
The biggest issue is deploying the software on various platforms such as various versions of windows. I had to work hard to create deployment packages which work with all old and new platforms. because we can’t dictate to users to make use of a particular platform.
Our biggest deployment issue is that our website resides on our customer’s servers. So, we have to remotely access all these servers and manually run the scripts for the db and then manually uninstall and install the application. It takes a lot of time and manpower.
Luckily we don’t have a timezone headache with our clients, so for us the biggest issue with deployment we currently have is the manual time and effort it currently takes, with the added risk that due to human nature deployments may not be 100% the same across the hundreds of sites.
In a nutshell that’s why we’re Automating everything and currently looking into Deployment manager…
Headaches for deployment we have quite a few:
1) Our production environment must be accessed manually via a key/FOB (that changes every 2 minutes) to gain vpn access. There is no VPN tunnel to production.
2) Databases are all in lockdown with respect to schema changes with the exception of a particular ssisUser SSMS account.
3) Databases are mirrored in production/staging but not dev and testing.
4) Time to just transfer the website files can approach 1 1/2 hrs.
5) Number of steps needed for complex deployments goes to 27 pages and is not run by the person putting together the steps. Leads to misunderstandings and error.
6) There is a highly complex ssis package, but working on it is all in complex sql script. Not all steps are captured there.
7) Some steps can now be automated, but our manpower to do so is no longer available.
8) We would like a push-button deployment from ccnet, but the hurtles to clear seem substantial.