User instance: Dubdubdeploy

When Donteormsby first contacted us, he simply wrote a friendly letter saying that he found a great tool to simplify the ASP.net site deployment and that our readers might be interested. After a further conversation, we think the best way to introduce Dubdub deployment is to let Donte tell the reader the story he has experienced personally.

If you know that a product is very helpful to you and would like to share your experience, be sure to inform us. We welcome both formal and informal user examples. Jonathanallen,netqueue, editor-in-chief.

Our story began in the second half of 2010, the Software Development Department of a local financial institution. As a software engineer for the project team, I was not only responsible for the coding of our applications, but also for the application server and deployment sites. Our system environment was still immature, so it was difficult to track all the applications through source code control and deploy to different servers.

We have a considerable number of Internet applications, from in-house applications to open Web pages to customer-facing portals. As a matter of course, each application has multiple environments and servers, usually production, testing, and development will have one or two environments, sometimes more, sometimes less. Application deployment is one of our major difficulties, with the exception of so many environments and the need to address infrastructure issues.

Each developer has 9 login Windows-4 different domain accounts (covering 3 domains), and 5 stand-alone servers with Non-domain accounts. Deploying to a server means logging on to the build server using one account and then logging on to the destination server with another account. The permanent mapping disk was not feasible at the time because there were so many things to deal with-dozens of applications were in different locations, many of which were obviously not based on server names or directories.

And not everyone is willing to remember the location of these dozens of applications, so these tasks fall to some of our chosen people. Because of the agile model, code is always updated quickly and deployed to different environments, and even production environments are often updated. Every day I have to keep putting down my work to deploy an application, which means I have to remember where this application is located, log on to a UNC share or map a new disk, then manually back up the files and manually deploy the new code. And I found out that when I was out of the office, everyone was afraid of deploying apps, or remembering passwords, or not knowing where they were supposed to put their files or files, anyway.

Between uninterrupted interruptions, delayed deployment of code to a test environment, and loss of productivity from publishing code to the wrong path, we've wasted several 10 hours a week, which can easily lead to a waste of hundreds of hours of valuable development time per year.

After recognizing the problem, my first attempt was to create a series of batch files that automatically map disks to the given application and environment. But it still means remembering 9 passwords and ensuring that all user accounts are in good condition (for some reason, this is not always true for us). This program is a little bit of a help, but we desperately need a more durable solution, a solution that everyone can safely use.

Then we found the dubdubdeploy that was still in the preview version. This product ensures that files are deployed across the web via HTTP rather than file system. This also means that all of our network access and user rights issues are gone. We decided to try it at that time. Even if we can only save a small fraction of the wasted time and energy, its free nature also let it value.

Dubdubdeploy only need to do a small installation on the compilation and the target Web server, and the configuration is very simple. We just need to define where the application can be copied and which user can run it. After the configuration is complete, backup and deployment turn from painful multi-step processes to an easy click.

And it also includes a Nant script builder and a cruisecontrol.net project configuration builder. We were already using these two products, but the generated samples gave us some insight into how to improve the quality of our scripts. For any formal project, you must have a solid compile process. I would welcome anything that would help improve the compilation strategy.

With all the applications and environments, our project team handles more than 40 common application deployment locations. Now Dubdubdeploy is recording everything according to the application and the environment, without having to recall or find it every time. If you want to deploy internal applications to QA, just open the panel and pull down to the intranet and click on the Deployment button under the QA server. After a few seconds, your application is deployed and you are ready to continue your work. Because it is so simple, now everyone can be responsible for their own deployment, without relying on others.

We also found other advantages in the use process. Ever since the deployment became a server to the server, the painful and lengthy process of using the VPN deployment code from home has now become as simple as being in the office. Dubdubdeploy consolidates cruisecontrol.net, we can monitor the compilation status in real time before deployment. When the compilation is complete, the application state turns green, which means we can deploy it securely.

It was a moment of such great change that everyone could now deploy. No work, no need to know the actual location of the file. The time to release an application is shortened from a few minutes to less than 10 seconds. Adding a branch to the Dubdubdeploy can take only a few minutes, even faster than deploying an application manually. We know we're moving on the right track.

Unfortunately, we are not allowed to use Dubdubdeploy in the production environment. It must establish a new communication link through HTTP and the target server, but our company does not allow this on the server. Even so, we save a lot of time on development and testing, which is exactly the most time we waste.

Now that we are not wasting time dealing with licensing and server-related issues, we have more time to engage in actual development work. As productivity soared, developers ' moods improved. As a developer, I always tend to encode or create cool new gadgets, rather than repetitive work or maintenance. Having more code-writing opportunities is a triumph for everyone.

Because this product is still a preview version, the function is still relatively small. We asked them to add some new features, some of which were quickly implemented. Now Dubdubdeploy can quickly find the difference between the source directory and the target directory, and only update the changed files, reduce the deployment time from 10 seconds to 2 seconds. At the same time we need to make it easier to create users: Users do not have to set security restrictions themselves, only to configure an ad group, and no longer for users to worry about security.

Although the product is new and its UI is rough, it helps a lot. I think it will be more helpful when it has more new features. In addition to a better user experience, the Dubdubdeploy team is also planning new features, such as scripted deployments, FTP deployments, deploying branching code through integrated source control, and integration with IIS. The team was very responsive to comments and suggestions, and for Dubdubdeploy, we communicated with the development team about the more potential uses we found, and we hope to see these improvements in the next major release.

A few months after using Dubdubdeploy to manage our deployments, we know that we have no way to turn back. Manual deployment, even in a simple environment, has been out of fashion.