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...
Shranjeno v:
| Glavni avtor: | |
|---|---|
| Format: | Knjiga |
| Jezik: | English |
| Izdano: |
Apress
2012
|
| Teme: | |
| Online dostop: | https://scholar.dlu.edu.vn/thuvienso/handle/DLU123456789/31198 |
| Oznake: |
Označite
Brez oznak, prvi označite!
|
| Thư viện lưu trữ: | Thư viện Trường Đại học Đà Lạt |
|---|
| Izvleček: | 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!/ |
|---|