Expert .NET Delivery Using NAnt and CruiseControl.NET
Delivering software? If you have bought this book, or grabbed it from a colleague’s desk, or even found it in the street and are looking at it with some interest, then I think it is quite likely that you have been struggling with the same problems as I have for some time. Successful build and rel...
Đã lưu trong:
Tác giả chính: | |
---|---|
Định dạng: | Sách |
Ngôn ngữ: | English |
Được phát hành: |
Apress
2012
|
Những chủ đề: | |
Truy cập trực tuyến: | http://scholar.dlu.edu.vn/thuvienso/handle/DLU123456789/31198 |
Các nhãn: |
Thêm thẻ
Không có thẻ, Là người đầu tiên thẻ bản ghi này!
|
Thư viện lưu trữ: | Thư viện Trường Đại học Đà Lạt |
---|
id |
oai:scholar.dlu.edu.vn:DLU123456789-31198 |
---|---|
record_format |
dspace |
spelling |
oai:scholar.dlu.edu.vn:DLU123456789-311982014-01-20T06:17:35Z Expert .NET Delivery Using NAnt and CruiseControl.NET Holmes, Marc Technologies Delivering software? If you have bought this book, or grabbed it from a colleague’s desk, or even found it in the street and are looking at it with some interest, then I think it is quite likely that you have been struggling with the same problems as I have for some time. Successful build and release processes seem to be easy when given some casual thought. In principle, moving and configuring a Windows or web application from development through testing and staging environments ultimately to production is quite straightforward. In practice, though—as I am sure you have found—the process can be considerably more complex. An application can have many aspects that require configuration as well as many assets to move around and store. A developer can easily miss these aspects. These factors can also go unnoticed for some time, and only cause a problem when the assets are needed “right now.” Builds and releases can take an extended amount of time. They will not usually “fail” in the sense that a piece of software is not delivered to the customer, but they will fail in various other ways. They may gradually add risk and complexity to the processes and reduce confidence in the platform. For example, they may rely on Bob being available because only he knows the configuration file. I am constantly disappointed by projects where difficulties are introduced by failing to look at these processes, among others. Some developers do not see these aspects of work as core to their role. Teams may produce excellent code and present some clever innovation in the software, only to find out that the development platform contains hundreds of zip files named things like “DontDeleteRegressionJustInCase” or a dozen SQL databases with dates appended to their name on a virtual server that now cannot be rebuilt because these assets have become an integral part of the system. And no one can be sure that they are an integral part of the system—Bob is on leave!/ 2012-08-09T01:16:40Z 2012-08-09T01:16:40Z 2005 Book 1-59059-485-1 http://scholar.dlu.edu.vn/thuvienso/handle/DLU123456789/31198 en application/pdf Apress |
institution |
Thư viện Trường Đại học Đà Lạt |
collection |
Thư viện số |
language |
English |
topic |
Technologies |
spellingShingle |
Technologies Holmes, Marc Expert .NET Delivery Using NAnt and CruiseControl.NET |
description |
Delivering software? If you have bought this book, or grabbed it from a colleague’s desk, or
even found it in the street and are looking at it with some interest, then I think it is quite likely
that you have been struggling with the same problems as I have for some time.
Successful build and release processes seem to be easy when given some casual thought.
In principle, moving and configuring a Windows or web application from development
through testing and staging environments ultimately to production is quite straightforward.
In practice, though—as I am sure you have found—the process can be considerably more
complex.
An application can have many aspects that require configuration as well as many assets
to move around and store. A developer can easily miss these aspects. These factors can also go
unnoticed for some time, and only cause a problem when the assets are needed “right now.”
Builds and releases can take an extended amount of time. They will not usually “fail” in
the sense that a piece of software is not delivered to the customer, but they will fail in various
other ways. They may gradually add risk and complexity to the processes and reduce confidence
in the platform. For example, they may rely on Bob being available because only he
knows the configuration file.
I am constantly disappointed by projects where difficulties are introduced by failing to
look at these processes, among others. Some developers do not see these aspects of work as
core to their role. Teams may produce excellent code and present some clever innovation in
the software, only to find out that the development platform contains hundreds of zip files
named things like “DontDeleteRegressionJustInCase” or a dozen SQL databases with dates
appended to their name on a virtual server that now cannot be rebuilt because these assets
have become an integral part of the system. And no one can be sure that they are an integral
part of the system—Bob is on leave!/ |
format |
Book |
author |
Holmes, Marc |
author_facet |
Holmes, Marc |
author_sort |
Holmes, Marc |
title |
Expert .NET Delivery Using NAnt and CruiseControl.NET |
title_short |
Expert .NET Delivery Using NAnt and CruiseControl.NET |
title_full |
Expert .NET Delivery Using NAnt and CruiseControl.NET |
title_fullStr |
Expert .NET Delivery Using NAnt and CruiseControl.NET |
title_full_unstemmed |
Expert .NET Delivery Using NAnt and CruiseControl.NET |
title_sort |
expert .net delivery using nant and cruisecontrol.net |
publisher |
Apress |
publishDate |
2012 |
url |
http://scholar.dlu.edu.vn/thuvienso/handle/DLU123456789/31198 |
_version_ |
1757653474028290048 |